Summary: | cannot break on static functions with gcc flto (link time optimization) | ||
---|---|---|---|
Product: | gdb | Reporter: | Xavier <chantry.xavier> |
Component: | breakpoints | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | tromey |
Priority: | P2 | ||
Version: | unknown | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | minimal test case with one static function foo |
Description
Xavier
2010-10-23 14:51:27 UTC
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. |