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

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

[steffen-schmidt at siemens dot com]

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.

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

[steffen-schmidt at siemens dot com]

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

--- Comment #1 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2011-11-16 13:27:59 UTC ---
Created attachment 6061
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6061
Startup code

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

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

[steffen-schmidt at siemens dot com]

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

--- Comment #2 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2011-11-16 13:28:35 UTC ---
Created attachment 6062
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6062
Main source file

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

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

[steffen-schmidt at siemens dot com]

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

Steffen Schmidt <steffen-schmidt at siemens dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steffen-schmidt at siemens
                   |                            |dot com

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

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

[tromey at redhat dot com]

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

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #3 from Tom Tromey <tromey at redhat dot com> 2011-11-16 20:52:18 UTC ---
I couldn't reproduce this using a plain native build on x86-64 F15.
All this really means is that I don't have a good way to try to debug it.
Maybe if you attached the executable, that would help.

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

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

[steffen-schmidt at siemens dot com]

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

--- Comment #4 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2011-11-17 07:41:26 UTC ---
Created attachment 6063
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6063
Test ELF File

I've attached the elf file for the test application. I hope this helps.

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

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

[tromey at redhat dot com]

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

--- Comment #5 from Tom Tromey <tromey at redhat dot com> 2011-11-17 15:14:52 UTC ---
(In reply to comment #4)
> Created attachment 6063 [details]
> Test ELF File
> 
> I've attached the elf file for the test application. I hope this helps.

Thanks.

Building a mips gcc to build a mips sim was too much, but I did try
with an ordinary multi-target gdb.

Setting a breakpoint seems to DTRT (this is with 7.3):

(gdb) set gnutarget elf32-tradlittlemips
(gdb) file ./pr-mips.exe 
Reading symbols from /home/tromey/gnu/PRS/gdb13415/pr-mips.exe...done.
(gdb) b ..\main.c:16
Breakpoint 1 at 0x4000dc: file ..\main.c, line 16.
(gdb) b ..\main.c:20
No line 20 in file "..\main.c".


So, something else must be going on.

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

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

[steffen-schmidt at siemens dot com]

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

--- Comment #6 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2011-11-21 07:46:16 UTC ---
(In reply to comment #5)
> So, something else must be going on.

How can I help to clearify this issue?

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

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

[tromey at redhat dot com]

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

--- Comment #7 from Tom Tromey <tromey at redhat dot com> 2012-01-25 17:25:06 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > So, something else must be going on.
> 
> How can I help to clearify this issue?

First, there was a big linespec change in 7.4 that might affect this.
So you could try that.

If it still fails then all there is to do is debug 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.

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

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
I ran across this today.  Using --gc-sections can end up with a
line table entry with a pc=0x0.  gdb will try to set a breakpoint
here (or at some offset, I was seeing 0x8) -- but of course that doesn't
work.

One idea would be to silently drop such entries.  That's what gdb
normally does with pc=0 in the DWARF reader (except when there is
a section including that address).

Another idea would be to warn and then drop these when setting a breakpoint.
That might be friendlier since it would alert the user that something
weird is going on.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

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

--- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
Note there's also bug #12528 on this topic.  And, patches did go in
to fix some problems with --gc-sections.

In the program that fails for me, the CU looks like:

 <0><199f>: Abbrev Number: 2 (DW_TAG_compile_unit)
    <19a0>   DW_AT_producer    : (indirect string, offset: 0x27da): GNU Ada
11.2.1 20210728 (Red Hat 11.2.1-1) -O -gnatez -gnatea -g -ffunction-sections
-gnatez -mtune=generic -march=x86-64
    <19a4>   DW_AT_language    : 13     (ADA 95)
    <19a5>   DW_AT_name        : (indirect line string, offset: 0x10d):
pack.adb
    <19a9>   DW_AT_comp_dir    : (indirect line string, offset: 0x0):
/home/tromey/AdaCore/gdb-testsuite/tests/KB21-043__bp_next_to_generic_fun
    <19ad>   DW_AT_ranges      : 0x63
    <19b1>   DW_AT_low_pc      : 0x0
    <19b9>   DW_AT_stmt_list   : 0x29e


low_pc == 0x0 is fishy, especially considering this is a native
Linux executable and not some embedded thing where it might make sense.

Also in the ranges:

    00000063 0000000000000000 000000000000003d 
    0000006d <End of list>

which is also pretty weird.

Maybe gdb ought to reject this entire CU, at least for purposes of
the line table.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

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

--- Comment #10 from Tom Tromey <tromey at sourceware dot org> ---
Created attachment 13901
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13901&action=edit
reproducer

This is the Ada reproducer for safekeeping.
I compiled with:

gnatmake m -g -O -ffunction-sections -largs -Wl,--gc-sections

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

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

--- Comment #11 from Tom Tromey <tromey at sourceware dot org> ---
Created attachment 13902
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13902&action=edit
patch

This patch improves the behavior somewhat:

(gdb) break pack.adb:10
Breakpoint 1 at 0x402354: file [...]/pack.adb, line 16.

This is consistent with the other gc-sections cases,
but it seems not quite ideal to me, because line 16 is
really in some other function.  It would be better to
get an error here, but that's a larger change involving
keeping the 0x0 entries around and then rejecting them
when setting the breakpoint.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.