Thanks for the thoughts!
> AIUI, -gsplit-dwarf is more suitable for development/scratch builds
> than for distro binaries. If distros agree, then I would not expect
> .dwo files to show up in distro-wide debuginfod services, but rather
> within developers' own build trees.
That's a good point. M
Hi -
> I'm concerned about using dwo IDs to index debuginfod. They are only
> 64-bits and there will be many more dwo IDs than build ids or
> supplemental file ids [...]
AIUI, -gsplit-dwarf is more suitable for development/scratch builds
than for distro binaries. If distros agree, then I would n
Hi Mark,
My apologies for bringing this up so late. I was just re-reading this thread
while looking at how to find a .dwp for a given binary.
> But I was personally assuming we would extend it to also to other things like
> dwo IDs (which are again almost identical globally unique identifiers for
Frank> (Does dwz'd dwarf5 even work on gdb
Frank> etc. now?)
It doesn't, this thread started because I sent a patch to change gdb to
read .debug_sup. This hasn't landed yet.
Tom
>> But, this seemed a bit weird. What if both appear and they are
>> different? Then a single API isn't so great -- you want to check the ID
>> corresponding to whatever was in the original file.
Frank> If both appear and are different, can we characterize the elf file as
Frank> malformed?
Not
Hi Mark,
$ git clone git://sourceware.org/git/dwz.git
$ cd dwz
$ ./configure
$ make
$ cp dwz one
$ cp dwz two
$ dwz --dwarf-5 -m sup one two
Thanks. Using those files as a guide I have added some initial support for
displaying and following .debug_sup sections to readelf and objdump.
Cheers
Hi -
> For dwz --dwarf-5, if it produced a .note.gnu.build-id, it would produce
> the same one, but I thought that if I produced that, then consumers could
> keep using that instead of .debug_sup which is the only thing defined
> in the standard, so in the end dwz --dwarf-5 only produces .debug_su
On Thu, Feb 25, 2021 at 11:42:45AM -0500, Frank Ch. Eigler via Dwz wrote:
> > FWIW I looked a little at unifying these. For example,
> > bfdopncls.c:bfd_get_alt_debug_link_info could look at both the build-id
> > and .debug_sup.
> >
> > But, this seemed a bit weird. What if both appear and they
Hi -
> FWIW I looked a little at unifying these. For example,
> bfdopncls.c:bfd_get_alt_debug_link_info could look at both the build-id
> and .debug_sup.
>
> But, this seemed a bit weird. What if both appear and they are
> different? Then a single API isn't so great -- you want to check the ID
> "Mark" == Mark Wielaard writes:
>> This patch adds support for this to gdb. It is largely
>> straightforward, I think, though one oddity is that I chose not to
>> have this code search the system build-id directories for the
>> supplementary file. My feeling was that, while it makes sense
Hi Nick,
On Wed, Feb 24, 2021 at 05:00:14PM +, Nick Clifton wrote:
> > Context is that dwz 0.15 (still not released yet) can now produce
> > standardized DWARF Supplementary Files using a .debug_sup section
> > when using --dwarf-5 -m multifile. See this bug report:
> > https://sourceware.org/
Hi Mark,
Context is that dwz 0.15 (still not released yet) can now produce
standardized DWARF Supplementary Files using a .debug_sup section
when using --dwarf-5 -m multifile. See this bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=27440
Is there somewhere that I can lay my hands
Hi,
I am adding the elfutils and dwz mailinglists to CC because I think
you stumbled upon a silent assumption debuginfod makes which would
be good to make explicit (or maybe change?)
Context is that dwz 0.15 (still not released yet) can now produce
standardized DWARF Supplementary Files using a .
13 matches
Mail list logo
