View Issue Details

IDProjectCategoryView StatusLast Update
0032240LazarusDebuggerpublic2021-01-10 12:10
ReporterChristo Crause Assigned ToMartin Friebe  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Platformx86_64OSLinux 
Product Version1.9 (SVN) 
Summary0032240: Continuous attempts to disassemble AVR target in Lazarus when stopped at break point
DescriptionWhen debugging AVR code via remote debugger (avr-gdb), recent gdb versions (7.1 - 8.0) cause an offset of 0x800000 to be added to the program memory location. This results in contents of the data memory to be disassembled. The debugger heuristics to disassemble the memory around the break point then fails because it doesn't get useful information back from gdb.
Steps To ReproduceRefer to Lazarus forum thread: http://forum.lazarus-ide.org/index.php/topic,37405.msg254652.html#msg254652
Additional InformationReport of gdb issue: https://sourceware.org/bugzilla/show_bug.cgi?id=13519

I suspect this will not be an issue for versions of gdb < 7.1

A patch has been submitted, but has been ignored for quite some time, so I suspect Lazarus users trying to debug remote AVR targets may encounter this issue if they have recent versions of gdb.
TagsAVR
Fixed in Revision
LazTarget
Widgetset
Attached Files

Relationships

related to 0034430 assignedMartin Friebe Assembler window is empty and "Cannot access memory at address <x>". 

Activities

Christo Crause

2017-08-04 22:15

reporter   ~0102064

A suggested work-around - perhaps the disassemble attempt should be aborted after a fixed number of tries. I cannot think of something that can be done from Lazarus's side to make the disassemble command work in avr-gd

Christo Crause

2021-01-10 11:31

reporter   ~0128238

I haven't encountered this particular bug for quite a while, I suggest this gets marked as "unable to reproduce" or "no change required" so that I can close this issue.

Martin Friebe

2021-01-10 12:10

manager   ~0128241

The related issue happens (afaik), if the IDE calculates an address in front of the exe memory.
Both issues therefore deal with invalid addresses.

The disassembling code needs a general overhaul. But this is currently lowest priority.
I want to keep both issues open, so that if/when I finally get to it, I know what to keep in mind.

Issue History

Date Modified Username Field Change
2017-08-04 22:08 Christo Crause New Issue
2017-08-04 22:08 Christo Crause Status new => assigned
2017-08-04 22:08 Christo Crause Assigned To => Martin Friebe
2017-08-04 22:09 Christo Crause Tag Attached: AVR
2017-08-04 22:15 Christo Crause Note Added: 0102064
2021-01-10 11:31 Christo Crause Note Added: 0128238
2021-01-10 12:07 Martin Friebe Relationship added related to 0034430
2021-01-10 12:10 Martin Friebe Note Added: 0128241