[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in 0.174 release
https://sourceware.org/bugzilla/show_bug.cgi?id=23673 --- Comment #4 from Martin Liska --- Created attachment 11257 --> https://sourceware.org/bugzilla/attachment.cgi?id=11257&action=edit openSUSE build log I'm attaching my build log. In general, I guess following flags are used: -std=gnu99 -Wall -Wshadow -Wformat=2 -Wold-style-definition -Wstrict-prototypes -Wlogical-op -Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5 -Werror -Wunused -Wextra -Wstack-usage=262144 -fPIC -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -- You are receiving this mail because: You are on the CC list for the bug.
Re: eh_frame is debug info too
Hi Sasha,
On Mon, 2018-09-17 at 21:18 +, Sasha Da Rocha Pinheiro wrote:
> So my point is: can we make dwarf_begin_elf() open binaries that only
> contain ".eh_frame" to further be able to call dwarf_cfi_addrframe?
I see your point and we have been more relax in determining what is or
isn't a real Dwarf file. Currently we allow a file that has a
.debug_info section or a .debug_line section or a .debug_frame section
(but up till 0.173 we only checked for .debug_info). Since those could
be used independently from each other.
But I am reluctant to make just having an .eh_frame enough. It really
isn't a debug/DWARF section. And as you also point out you don't need a
Dwarf handle for it. You would call dwarf_getcfi_elf (Elf *elf) to get
the CFI.
Allowing just .eh_frame being present would basically make any Elf file
a valid Dwarf file. I am somewhat worried that some existing programs
first try to open a file as Dwarf and only when it fails try to lookup
the separate debug file they need. We would break such programs.
I would note here that often the Dwarf debug file and the main Elf file
might not be the same (in the case of separate .debug file). And that
case you should really combine the CFI from the .debug_frame and the
CFI from the .eh_frame. They might cover different address ranges.
> To make it more clear, in a Dyninst class, at some point, only has a
> Dwarf * handle. It doesn't know if it is stripped with only
> ".eh_frame" or if it contains ".debug_frame" and/or "eh_frame".
> What it does is try get both from the same handle as follows:
>
> // Try to get dwarf data from .debug_frame
> Dwarf_CFI * cfi = dwarf_getcfi(dbg);
> if (cfi)
> {
> cfi_data.push_back(cfi);
> }
>
> // Try to get dwarf data from .eh_frame
> Elf * elf = dwarf_getelf(dbg);
> cfi = dwarf_getcfi_elf(elf);
> if (cfi)
> {
> cfi_data.push_back(cfi);
> }
>
> Note that we try with dwarf_getcfi (for the .debug_frame section)
> giving the handle "dbg", and afterwards we have to get the Elf handle
> of this dwarf handle "dbg" to use dwarf_getcfi_elf (for the .eh_frame
> section).
So in the above how does that work with a binary that has separate
debuginfo? (Do you use libdwfl, or dwelf_elf_gnu_debuglink or use
dwelf_elf_gnu_build_id to find it?) In that case dwarf_getelf () will
return the file containing the separate debuginfo, but the .eh_frame
would be in the main Elf file.
Also note that the returned cfi has different life-times. The Dwarf_CFI
handle you get from dwarf_getcfi () is valid till the associated Dwarf
handle is closed. The Dwarf_CFI returned from dwarf_getcfi_elf is owned
by (and should be freed by) the called (and you will get a new one each
call). So be careful you don't have a memory leak here.
Cheers,
Mark
[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in 0.174 release
https://sourceware.org/bugzilla/show_bug.cgi?id=23673 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Mark Wielaard --- We reviewed this on irc and came to the surprising conclusion that this was caused by ptrace TRACEME failing with EPERM. That is really odd. But not a bug in elfutils IMHO. -- You are receiving this mail because: You are on the CC list for the bug.
Re: eh_frame is debug info too
It's not working but I'm fixing it.
We don't use Elfutils to find the corresponding separate debug info. It was
already implemented by searching the gnu_debuglink section and getting the info.
Sasha
From: Mark Wielaard
Sent: Tuesday, September 18, 2018 6:36 AM
To: Sasha Da Rocha Pinheiro; elfutils-devel@sourceware.org
Subject: Re: eh_frame is debug info too
Hi Sasha,
On Mon, 2018-09-17 at 21:18 +, Sasha Da Rocha Pinheiro wrote:
> So my point is: can we make dwarf_begin_elf() open binaries that only
> contain ".eh_frame" to further be able to call dwarf_cfi_addrframe?
I see your point and we have been more relax in determining what is or
isn't a real Dwarf file. Currently we allow a file that has a
.debug_info section or a .debug_line section or a .debug_frame section
(but up till 0.173 we only checked for .debug_info). Since those could
be used independently from each other.
But I am reluctant to make just having an .eh_frame enough. It really
isn't a debug/DWARF section. And as you also point out you don't need a
Dwarf handle for it. You would call dwarf_getcfi_elf (Elf *elf) to get
the CFI.
Allowing just .eh_frame being present would basically make any Elf file
a valid Dwarf file. I am somewhat worried that some existing programs
first try to open a file as Dwarf and only when it fails try to lookup
the separate debug file they need. We would break such programs.
I would note here that often the Dwarf debug file and the main Elf file
might not be the same (in the case of separate .debug file). And that
case you should really combine the CFI from the .debug_frame and the
CFI from the .eh_frame. They might cover different address ranges.
> To make it more clear, in a Dyninst class, at some point, only has a
> Dwarf * handle. It doesn't know if it is stripped with only
> ".eh_frame" or if it contains ".debug_frame" and/or "eh_frame".
> What it does is try get both from the same handle as follows:
>
> // Try to get dwarf data from .debug_frame
> Dwarf_CFI * cfi = dwarf_getcfi(dbg);
> if (cfi)
> {
> cfi_data.push_back(cfi);
> }
>
> // Try to get dwarf data from .eh_frame
> Elf * elf = dwarf_getelf(dbg);
> cfi = dwarf_getcfi_elf(elf);
> if (cfi)
> {
> cfi_data.push_back(cfi);
> }
>
> Note that we try with dwarf_getcfi (for the .debug_frame section)
> giving the handle "dbg", and afterwards we have to get the Elf handle
> of this dwarf handle "dbg" to use dwarf_getcfi_elf (for the .eh_frame
> section).
So in the above how does that work with a binary that has separate
debuginfo? (Do you use libdwfl, or dwelf_elf_gnu_debuglink or use
dwelf_elf_gnu_build_id to find it?) In that case dwarf_getelf () will
return the file containing the separate debuginfo, but the .eh_frame
would be in the main Elf file.
Also note that the returned cfi has different life-times. The Dwarf_CFI
handle you get from dwarf_getcfi () is valid till the associated Dwarf
handle is closed. The Dwarf_CFI returned from dwarf_getcfi_elf is owned
by (and should be freed by) the called (and you will get a new one each
call). So be careful you don't have a memory leak here.
Cheers,
Mark
