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
12 matches
Mail list logo
