From: David Blaikie <dblaikie@gmail.com>
To: Adrian Prantl <aprantl@apple.com>
Cc: Eric Christopher <echristo@gmail.com>,
Simon Marchi <simon.marchi@polymtl.ca>,
Tom Tromey <tom@tromey.com>,
Jordan Rupprecht <rupprecht@google.com>,
gdb-patches <gdb-patches@sourceware.org>,
Douglas Evans <dje@google.com>
Subject: Re: [PATCH] [dwarf2read] Fix crash when loading dwp files: calculate num_sections based on actual section indices, not just the number of sections.
Date: Wed, 27 Feb 2019 19:33:00 -0000 [thread overview]
Message-ID: <CAENS6Evor5coxyAxD8M_KnespW5b6AN00X6KedJdOetYosDHJw@mail.gmail.com> (raw)
In-Reply-To: <43BCD0FD-28C3-49E5-B7CB-4E18ACFBA646@apple.com>
On Wed, Feb 27, 2019 at 10:05 AM Adrian Prantl <aprantl@apple.com> wrote:
> Split DWARF solves a problem that doesn't exist on Darwin (macOS/iOS,
> ...). The motivation behind split DWARF is to reduce the number of
> relocations in debug info that have to be processed by the linker. But on
> Darwin, debug info is not processed by the linker at all, instead a tool
> called dsymutil (cf. llvm/tools/dsymutil) serves a conceptually similar
> task to dwp and archives the debug info from the .o files into a .dSYM
> bundle, separate from the executable.
>
Same conclusion (Darwin isn't interested in Split DWARF), but slightly
different reasons:
Split DWARF was intended to reduce the number of bytes needed to be sent to
the linker - that problem exists in the current Darwin distribution model,
but no one on Darwin seems to have found it to be a problem in practice
(basically it was a problem for Google - anyone using a distributed build
might eventually have this as a concern/bottleneck/problem).
(Split DWARF also reduces the size of the final binary, which is also
valuable - and Darwin doesn't have that problem. Basically Darwin's
distribution model is more or less like the "single file Split DWARF" mode
that the DWARFv5 spec talks about - where you don't actually split it into
a separate file, but you leave it in sections the linker will
discard/ignore)
But yeah, the LLVM implementations of Split DWARF and DWP haven't taken any
real concern to work on anything other than ELF, to the best of my
knowledge (of the parts I worked on, of the parts I've worked with, etc).
- Dave
>
> -- adrian
>
> > On Feb 27, 2019, at 9:56 AM, Eric Christopher <echristo@gmail.com>
> wrote:
> >
> > (Adding in Adrian)
> >
> > While llvm-dwp will run just fine on osx as a program, it's not
> > intended for the platform. I don't know if there are any plans for
> > dwarf5-esque split dwarf on apple platforms. Adrian might be able to
> > comment more.
> >
> > -eric
> >
> > On Wed, Feb 27, 2019 at 9:40 AM Simon Marchi <simon.marchi@polymtl.ca>
> wrote:
> >>
> >> On 2019-02-27 12:22, Tom Tromey wrote:
> >>>>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
> >>>
> >>> Simon> So my impression now is that dwp doesn't apply to non-ELF
> >>> projects.
> >>> Simon> It is built as part of gold, which itself deals only with ELF,
> >>> AFAIK.
> >>> Simon> I tried to build gold on AIX, without success.
> >>>
> >>> I think there's also llvm-dwp. Does it work on Mach-O?
> >>>
> >>> Tom
> >>
> >> Of course, there's llvm-dwp, it's the reason this patch was written :).
> >>
> >> Maybe David (in CC) can help answer this?
> >>
> >> Simon
>
>
prev parent reply other threads:[~2019-02-27 19:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-23 0:54 Jordan Rupprecht via gdb-patches
2019-02-24 4:01 ` Simon Marchi
2019-02-25 20:17 ` Jordan Rupprecht via gdb-patches
2019-02-25 20:21 ` Simon Marchi
2019-02-25 20:21 ` Jordan Rupprecht via gdb-patches
2019-02-25 20:55 ` Simon Marchi
2019-02-25 21:22 ` Jordan Rupprecht via gdb-patches
2019-02-26 15:08 ` Tom Tromey
2019-02-26 16:24 ` Simon Marchi
2019-02-27 4:41 ` Simon Marchi
2019-02-27 17:22 ` Tom Tromey
2019-02-27 17:40 ` Simon Marchi
2019-02-27 17:56 ` Eric Christopher
2019-02-27 18:06 ` Adrian Prantl
2019-02-27 18:13 ` Simon Marchi
2019-02-27 19:33 ` David Blaikie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAENS6Evor5coxyAxD8M_KnespW5b6AN00X6KedJdOetYosDHJw@mail.gmail.com \
--to=dblaikie@gmail.com \
--cc=aprantl@apple.com \
--cc=dje@google.com \
--cc=echristo@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=rupprecht@google.com \
--cc=simon.marchi@polymtl.ca \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox