[Bug gdb/12299] New: AVR ATMEGA128 Assembly Files lead to RAM Breakpoint Addr. 0x00800000++
bugzilla at dr dot eit.h-da.de
sourceware-bugzilla@sourceware.org
Wed Dec 8 18:55:00 GMT 2010
http://sourceware.org/bugzilla/show_bug.cgi?id=12299
Summary: AVR ATMEGA128 Assembly Files lead to RAM Breakpoint
Addr. 0x00800000++
Product: gdb
Version: 7.2
Status: NEW
Severity: normal
Priority: P2
Component: gdb
AssignedTo: unassigned@sourceware.org
ReportedBy: bugzilla@dr.eit.h-da.de
Created attachment 5148
--> http://sourceware.org/bugzilla/attachment.cgi?id=5148
avr ATMEGA128 elf file with startaddr 0x50 (symbol main)
Assembler only Project.
When using gcc to assemble *.s files, the avr-gdb treats all addresses
as RAM addresses 0x0080XXXX (Harvard mapping RAM to von-Neumann addr space)
f.ex. a gdb command 'disass 0x50,0x56' goes into the RAM-location
0x00800050 and disassembles there:
(gdb) disass 0x50,0x56
Dump of assembler code from 0x800050 to 0x800056:
0x00800050: Cannot access memory at address 0x800050
(gdb)
In disasm.c/390 the code
low &= 0x007fffff;
high &= 0x007fffff;
would repair this but probably at the wrong place since in breakpoint.c/5285
return bpaddr & 0x007FFFFF
repairs (some) wrong breakpoint addresses...
If calling a assembly language routine from within a C-pgm and running into
the assembler part with breakpoints is working.
Attaching a elf binary to allow for disasm 0x50,0x56.
0x00000050 <main+0>: ldi r16, 0xFF ; 255
0x00000052 <main+2>: sts 0x005D, r16
The symbol 'main' should have the addr 0x50. The debugger reports 0x52 (wrong):
(gdb) b main
Breakpoint 1 at 0x52: file ../main.s, line 12.
(gdb)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the Gdb-prs
mailing list