Created attachment 5082 [details] minimal test case with one static function foo When compiling with gcc -flto, static symbols get a number suffix/extension. e.g. foo becomes foo.2043 break foo<tab> expands to break foo.2043, but neither works. The only way to actually set the break point is to specify the address directly. [xavier@xps-m1530 ~]$ gcc -flto test.c [xavier@xps-m1530 ~]$ objdump -d a.out | grep foo 00000000004004c4 <foo.2043>: 4004d8: e8 e7 ff ff ff callq 4004c4 <foo.2043> [xavier@xps-m1530 ~]$ gdb a.out GNU gdb (GDB) 7.2.50.20101022-cvs Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/xavier/a.out...(no debugging symbols found)...done. (gdb) break foo.2043 Can't find member of namespace, class, struct, or union named "foo.2043" Hint: try 'foo.2043<TAB> or 'foo.2043<ESC-?> (Note leading single quote.) Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (foo.2043) pending. (gdb) break foo Function "foo" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 2 (foo) pending. (gdb) run Starting program: /home/xavier/a.out bar Program exited with code 04. (gdb) break *0x4004c4 Breakpoint 3 at 0x4004c4 (gdb) run Starting program: /home/xavier/a.out Breakpoint 3, 0x00000000004004c4 in foo.2043 () (gdb) c Continuing. bar Program exited with code 04. (gdb)
Try the hint that gdb suggests: Hint: try 'foo.2043<TAB> or 'foo.2043<ESC-?> So: break 'foo.2043' I think this could be better, so I'm leaving the PR open. Also, I think this is an LTO bug. It seems to me that it should emit debuginfo naming the symbol as "foo".
(In reply to comment #1) > Try the hint that gdb suggests: > > Hint: try 'foo.2043<TAB> or 'foo.2043<ESC-?> > > So: break 'foo.2043' > > I think this could be better, so I'm leaving the PR open. > I don't remember if I tried this or not before, I just remember I was a bit confused by this message. Anyway 'foo.2043<TAB> expands to 'foo.2043', but the behavior is exactly the same. (gdb) break 'foo.2043 Can't find member of namespace, class, struct, or union named "foo.2043" Hint: try 'foo.2043<TAB> or 'foo.2043<ESC-?> (Note leading single quote.) Make breakpoint pending on future shared library load? (y or [n]) > Also, I think this is an LTO bug. It seems to me that it should emit > debuginfo naming the symbol as "foo". Shall I report it to gcc bugtracker then? I was wondering if this was simply a bug and if there was not a reason for this naming. In gcc man page about -flto, there is : Link time optimization does not play well with generating debugging information. Combining -flto or -fwhopr with -g is experimental. Without -flto, I don't need to build with -g to get symbol names, I can break on any functions. I only need -g if I want to get the source, see the parameters of functions, etc. So I wonder if this warning message captures the 'foo.2043' problem.