[Bug backends/23902] New: varlocs dwarf_cfi_addrframe: unknown error

[kurt at roeckx dot be]

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

Bug ID: 23902
Summary: varlocs dwarf_cfi_addrframe: unknown error
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: backends
Assignee: unassigned at sourceware dot org
Reporter: kurt at roeckx dot be
CC: elfutils-devel at sourceware dot org
Target Milestone: ---

On at least mips, alpha and hppa, I'm getting something like:
/<<PKGBUILDDIR>>/tests/varlocs: dwarf_cfi_addrframe 0x120002540: unknown error
*** failure in /<<PKGBUILDDIR>>/tests/varlocs -e /<<PKGBUILDDIR>>/src/addr2line

Logs can be found at:
https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=alpha&ver=0.175-1&stamp=1542672225&raw=0
https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=mips&ver=0.175-1&stamp=1542667301&raw=0
https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=hppa&ver=0.175-1&stamp=1542666561&raw=0

The mips and hppa backend are patches that only exist in Debian, but alpha
seems to be part of upstream.

Is this some indication of missing functionality? Any suggestion where to look?

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at klomp dot org

--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
The common theme might be that these arches don't use standard .eh_frame and/or
have some non-standard section name or type for the unwind tables?

alpha does have an upstream backend, but I am not sure when it was last tested.

[kurt at roeckx dot be]

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

--- Comment #2 from Kurt Roeckx <kurt at roeckx dot be> ---
At least on mips I'm seeing an .eh_frame and .eh_frame_hdr section. It also has
some mips specific sections.

But note that various of the other tests say "Unwinding not supported for this
architecture". Is this just a test that also should get skipped?

PS: All arches except amd64 have "Unwinding not supported for this
architecture" in run-backtrace-data.sh, which I find a bit surprising.

[mark at klomp dot org]

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

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Kurt Roeckx from comment #2)

Post by kurt at roeckx dot be
At least on mips I'm seeing an .eh_frame and .eh_frame_hdr section. It also
has some mips specific sections.

Assuming they have "normal" types then that part should work because it is
(mostly, except for register mapping) arch independent.

Post by kurt at roeckx dot be
But note that various of the other tests say "Unwinding not supported for
this architecture". Is this just a test that also should get skipped?

If it would return that error maybe. But the varlocs test doesn't rely on
unwinding. There is something odd going on because it gives "Unknown Error",
which is not explicitly set anywhere in the code, but is generated when
__libelf_seterrno () is called with an unknown error code (which itself is a
bug). So something doubly odd is going on.

Post by kurt at roeckx dot be
PS: All arches except amd64 have "Unwinding not supported for this
architecture" in run-backtrace-data.sh, which I find a bit surprising.

Yes, that is surprising, run-backtrace-data.sh really should just say that it
is only supported on x86_64/amd64. Currently it "abuses" the "Unwinding not
supported for this architecture" message to get a SKIP on any other arch.

[kurt at roeckx dot be]

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

--- Comment #4 from Kurt Roeckx <kurt at roeckx dot be> ---
The varlocs test is calling dwarf_errmsg (-1)

[mark at klomp dot org]

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

--- Comment #5 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Kurt Roeckx from comment #4)

Post by kurt at roeckx dot be
The varlocs test is calling dwarf_errmsg (-1)

OK, that will show the last libdw error set on the current thread.
In which case we might actually have a candidate for why it was set.
The only place DWARF_E_UNKNOWN_ERROR is set (returned) is:

libdw/cfi.c (cie_cache_initial_state):

/* Fetch the ABI's default CFI program. */
if (likely (cache->ebl != (void *) -1l)
&& unlikely (ebl_abi_cfi (cache->ebl, &abi_info) < 0))
return DWARF_E_UNKNOWN_ERROR;

That would explain the issue on alpha at least because that doesn't have a
backend hook for abi_cfi. I suspect your mips and hppa backends also don't have
that hooked.

[kurt at roeckx dot be]

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

--- Comment #6 from Kurt Roeckx <kurt at roeckx dot be> ---
Yes, they all 3 seem to be missing that callback.

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|varlocs |varlocs
|dwarf_cfi_addrframe: |dwarf_cfi_addrframe:
|unknown error |unknown error (missing ebl
| |abi_cfi hook)

--- Comment #7 from Mark Wielaard <mark at klomp dot org> ---
The ebl abi_cfi hook sets up the initial CFI instructions, default data
alignment factor and return address register for the architecture. These are
normally given in the System V Application Binary Interface Processor
Supplement for a specific architecture which also explain the DWARF register
mappings.