[Bug breakpoints/13415] New: Invalid breakpoints when linking with--gc-sections

["steffen-schmidt at siemens dot com"<sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13415

             Bug #: 13415
           Summary: Invalid breakpoints when linking with --gc-sections
           Product: gdb
           Version: 7.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
        AssignedTo: unassigned@sourceware.org
        ReportedBy: steffen-schmidt@siemens.com
    Classification: Unclassified


Created attachment 6060
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6060
Mapfile

On mips-sde-elf target we're commonly using compiler option -ffunction-sections
in combination with linker option --gc-sections to reduce memory footprint of
the generated code. Both options combined enable the linker to throw out all
the functions, that are actually not called in the application.

I've provided a small example application (for MIPS32, although this problem
also occurs on other platforms, like arm-elf). This application contains 2
files, start.S and main.c.
To compile I'm using a mips32 gcc, for little endian.

mips-sde-elf-gcc.exe -mips32r2 -EL -c -o start.o start.S

mips-sde-elf-gcc.exe -O0 -g3 -Wall -c -fmessage-length=0 -ffunction-sections
-fdata-sections -mips32r2 -EL -o main.o main.c

mips-sde-elf-ld.exe -Lmips-sde-elf\lib\el -Llib\gcc\mips-sde-elf\4.5.2\el
-mips32r2 -EL --gc-sections -Map=mapfile.map -o TestGCandDebugMIPS32.elf
--start-group start.o main.o lib\gcc\mips-sde-elf\4.5.2\el\crtbegin.o
lib\gcc\mips-sde-elf\4.5.2\el\crtend.o -lgcc -lc --end-group

According to the map file, the garbage collected functions are linked to
address 0x0, see appended mapfile.map function func_notused, whereas a used
function is linked to a valid address:

text.func_notused  0x0000000000000000 0x34 main.o
text.func_used     0x00000000004000cc 0x34 main.o

I'm debugging using mips-sde-elf GDB and target sim:
target sim
sim endian little
sim memory-size 256m
file TestGCandDebugMIPS32.elf
load
b main
run

If you now try to set a breakpoint to the garbage collected function
func_notused GDB will tell you, that it does not know the symbol, that's
correct.

(gdb) break func_used
Breakpoint 2 at 0x4000dc: file ..\main.c, line 16.
(gdb) break func_notused
Function "func_notused" not defined.

If you, on the other hand, set a breakpoint into a garbage collected functions
using GDB "break <file>:<line> command, the debugger tries to set the
breakpoint, although the function is actually not there. The breakpoint will be
set somewhere near address 0x0, because that's the address the function was
linked to.

(gdb) break main.c:16  <-- this is in func_used
Breakpoint 3 at 0x4000dc: file ..\main.c, line 16.  <-- okay
(gdb) break main.c:20  <-- this is in func_unused
Breakpoint 4 at 0x10: file ..\main.c, line 20.  <-- this is an invalid address
(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x004000ac in main at ..\main.c:9
2       breakpoint     keep y   0x004000dc in func_used at ..\main.c:16
3       breakpoint     keep y   0x004000dc in func_used at ..\main.c:16
4       breakpoint     keep y   0x00000010 ..\main.c:20

This results in unexpected behaviour, depending on what's actually at this
address. Especially, the addresses might not even be accessible on some
platforms, resulting in a warning: "cannot insert breakpoint at 0x10", causing
the GDB to not even start running the program until this breakpoint is deleted.


Can GDB be aware of such a situation, not setting such breakpoints? GDB seems
know, which function to set the breakpoint to, because the offset to the
functions start seems correct. 

GDB should give a warning, that it could not set the breakpoint, but
nevertheless start running when calling continue. The invalid breakpoint should
probably not even occurr in the breakpoint table.
Is this possible?

-- 
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.