public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "steffen-schmidt at siemens dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug breakpoints/13415] New: Invalid breakpoints when linking with --gc-sections Date: Wed, 16 Nov 2011 13:27:00 -0000 [thread overview] Message-ID: <bug-13415-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2011-11-16 13:27 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-11-16 13:27 steffen-schmidt at siemens dot com [this message] 2011-11-16 13:28 ` [Bug breakpoints/13415] " steffen-schmidt at siemens dot com 2011-11-16 13:28 ` steffen-schmidt at siemens dot com 2011-11-16 13:30 ` steffen-schmidt at siemens dot com 2011-11-16 20:53 ` tromey at redhat dot com 2011-11-17 7:41 ` steffen-schmidt at siemens dot com 2011-11-17 15:15 ` tromey at redhat dot com 2011-11-21 7:46 ` steffen-schmidt at siemens dot com 2012-01-25 17:26 ` tromey at redhat dot com 2022-01-07 21:54 ` tromey at sourceware dot org 2022-01-11 17:30 ` tromey at sourceware dot org 2022-01-11 17:32 ` tromey at sourceware dot org 2022-01-11 18:20 ` tromey at sourceware dot org 2024-03-15 9:16 ` sam at gentoo dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-13415-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).