[PATCH] D19236: Add DITypeIndex for CodeView and emit it for locals

[David Blaikie via llvm-commits]

On Thu, Apr 21, 2016 at 2:31 PM, Aboud, Amjad <amjad.aboud at intel.com> wrote:

> I am not convinced that you are going the right direction.
>
> Not only that, now you are confusing me with the double motivation, I
> asked you before on the proposal of improving debug info if the motivation
> was CodeView and you said “no”.
>

CodeView is the proximal/immediate motivation for the work. The choice of
work is motivated by what we think will be a good overall direction.


> Now, you claim that the motivation is fast implementation for CodeView.
>
> I think it is easier/faster/doable to emit CodeView from current Dwarf
> Metadata,
>

Not currently, we'd have to do a bunch of work to plumb through more
information into the DWARF metadata scheme. The argument is that that's the
tipping point to trying something different - that there's enough
engineering work there that we think, in the long run, would be obsoleted
by doing an up-front emission, that we should just start putting work
behind that instead.


> for sure more than you will be able to do with the Blobs/MDStrings that
> you do not explain yet how it will look like.
>

I'm not sure I understand this ^ statement, sorry.


> I can simply let you commit this patch that adds nothing to what we can do
> today, but you will need to prove that the next patch (when you support
> compound types) will work more than we can implement today with what we
> have in dwarf.
>

I think it's already been covered in the RFC, etc, the sort of information
required for the Windows ABI (moreso in terms of complexity/differences in
the way runtime polymorphism is implemented (quite different from Itanium -
different constructs that need to be described, etc)) is substantially
different in enough ways from Itanium that it cannot be implemented with
the existing DWARF metadata - the DWARF Metadata schema describes Itanium
ABI constructs, not Windows ABI constructs.

Yes, we could add them to the DWARF Metadata and hold both (or a union
where one or the other is provided), but the bet is that all the extra
complexity would eventually be removed anyway as we eventually migrate to
up-front emission. So we might as well get started on that now, rather than
do a bunch of work we'll throw out anyway.


> If your approach will fail, will you consider revert and go back to one
> representation of debug info (Dwarf based or whatever) and do the simple
> extra work in the backend to emit the format needed by the target?
>

If it turns out this path is unachievable (though we really have a pretty
good basis to believe it's achievable - it's essentially the architecture
Microsoft's compiler uses and the way the CodeView format is designed to
handle type information) I'm sure we'll re-evaluate about what the right
path forward is. Depending on why it's unachievable, maybe the answer will
be to extend the existing metadata type schema with the extra information,
maybe it'll be something else. I expect we'll cross that river should we
come to it.

- David


>
>
> Thanks,
>
> Amjad
>
>
>
> *From:* Reid Kleckner [mailto:rnk at google.com]
> *Sent:* Thursday, April 21, 2016 23:44
> *To:* David Blaikie <dblaikie at gmail.com>
> *Cc:* reviews+D19236+public+b02ee3c2b2d2b281 at reviews.llvm.org; Aboud,
> Amjad <amjad.aboud at intel.com>; Duncan P. N. Exon Smith <
> dexonsmith at apple.com>; Eric Christopher <echristo at gmail.com>; Adrian
> Prantl <aprantl at apple.com>; llvm-commits <llvm-commits at lists.llvm.org>
> *Subject:* Re: [PATCH] D19236: Add DITypeIndex for CodeView and emit it
> for locals
>
>
>
> On Thu, Apr 21, 2016 at 10:45 AM, David Blaikie <dblaikie at gmail.com>
> wrote:
>
> 2.d. Do you have estimation on how much size the "llvm.dbg.cvtypes" will
> consume? Can you assure we will end up reducing the IR size and not
> increasing it?
> 3. If the idea is to reduce the size of the LTO IR, why we are not doing
> this also for DWARF, why just for CV types?
>
>
>
> Because that's a lot of work that's not needed right now. Right now the
> need is to emit CodeView debug info. The goal is to use the motivation here
> to experiment with something we've been considering for a while and, if it
> seems like a good path forward we can port DWARF over to it at some point
> in the future when someone decides they want to save a few more bytes and
> cycles.
>
>
>
> Yes, thanks for writing that! That's a good way to put it: collectively,
> we think emitting debug types in the frontend is the right design long
> term, for both coupling and efficiency reasons. Doing it for DWARF is a
> large amount of work, and nobody has immediate plans to do it. CodeView,
> however, does need work, and this is a good opportunity to experiment with
> up front type emission.
>
>
>
> I meant to respond to the RFC with something along those lines, but
> writing patches is so much more attractive than writing email...
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160421/6a76e433/attachment.html>