Bug 60240 - libbacktrace problems with nested functions
Summary: libbacktrace problems with nested functions
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libbacktrace (show other bugs)
Version: 4.8.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-17 11:50 UTC by Johannes Pfau
Modified: 2019-02-09 19:40 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
test case to reproduce the bug (270 bytes, text/x-chdr)
2014-02-17 11:50 UTC, Johannes Pfau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Pfau 2014-02-17 11:50:51 UTC
Created attachment 32152 [details]
test case to reproduce the bug

Compile the test case with "-lbacktrace -g".

Actual output:
test.c:17 (null)

Expected output: The backtrace should contain the function name ('a') instead of null.

AFAICS the problem is in read_function_entry. There's a "abbrev->has_children" check that assumes all children of a function are inlined instances of the same function. This is not true, children can also be nested functions. libbacktrace should check the "DW_AT_inline" tag here.
Comment 1 Tom de Vries 2019-02-09 14:09:35 UTC
I can reproduce this.

But, I wonder if this an actual bug, given that the address of the nested function that is passed as argument to backtrace_pcinfo is either a trampoline on stack or some function descriptor ( https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html ).

Using a backtrace_print from a nested function works fine.

I propose to mark this resolved-invalid.
Comment 2 Ian Lance Taylor 2019-02-09 19:40:30 UTC
I agree that this example cannot be expected to work.  The docs for backtrace_pcinfo say that the function works when "Given PC, a program counter in the current program."  The value (uintptr_t)&a is not a program counter in the current program.