[Bug gdb/12299] New: AVR ATMEGA128 Assembly Files lead to RAMBreakpoint Addr. 0x00800000++

["bugzilla at dr dot eit.h-da.de" <sourceware-bugzilla at sourceware dot org>]

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.