similar to: [cfe-dev] RFC: Up front type information generation in clang and llvm

The split between CodeView and DWARF will happen at the level of type information. So, DIVariable, DISubprogram, DILocation, DILocalScope, etc will all be shared, but records and composite types etc will not. On Thu, Mar 31, 2016 at 3:44 PM, Aboud, Amjad via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Mehdi, > > I understand the reasoning for supporting this proposal

Hi Eric, I'm coming back on this topic after discussing this offline quickly with Reid, and at length with Adrian, Duncan, and Fred. I may have to take back some of my words from my previous email, especially as it is not clear how and why what Reid is proposing to do is hurting a future path for Dwarf. Especially, if my understanding is correct, the key point that differentiate what Reid is

>-----Original Message----- >From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Reid >Kleckner via cfe-dev >Sent: Wednesday, May 11, 2016 10:40 AM >To: Mehdi Amini <mehdi.amini at apple.com> >Cc: llvm-dev <llvm-dev at lists.llvm.org>; Clang Dev <cfe-dev at lists.llvm.org> >Subject: Re: [cfe-dev] [llvm-dev] RFC: Up front type information

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM

I also think that we should keep one representation of debug info in the LLVM IR. There would be a need to extend some of the debug info entries to support CodeView, but I think that most of the information generated today by Clang for Dwarf can be used for generating CodeView. I can think about two missing extensions that are needed to CodeView: 1. In Frontend: File Checksum, it is

Hi All, This is something that's been talked about for some time and it's probably time to propose it. The "We" in this document is everyone on the cc line plus me. Please go ahead and take a look. Thanks! -eric Objective (and TL;DR) ================= Migrate debug type information generation from the backends to the front end. This will enable: 1. Separation of

Hi Aboud, > On Mar 31, 2016, at 11:06 AM, Aboud, Amjad via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Hi Eric, > I can understand the need for improving the current design of debug info representation and emission in LLVM. > However, let’s not forget that the motivation was and still to support CodeView debug info emission. Well, that is *one* motivation. > I am

> On Mar 31, 2016, at 7:11 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > > On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul <Paul_Robinson at playstation.sony.com

I don't agree in general here because of: a) maintainability - there isn't a one true path through things and now is scattering more windows knowledge through debug info and lto b) higher bar for implementing similar dwarf functionality - there's nothing here that makes it at any point better for our general debug info support. Incrementally updating to an intermediate step is much

> On Mar 31, 2016, at 8:50 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 31, 2016, at 7:11 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev <cfe-dev at lists.llvm.org

On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > Skipping a serialization and doing something clever about LTO uniquing > sounds awesome. I'm guessing you achieve this by extracting types out of > DI metadata and packaging them as lumps-o-DWARF that the back-end can then > paste together? Reading between the lines a bit

On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul < > Paul_Robinson at playstation.sony.com> wrote: > >> Skipping a serialization and doing something clever about LTO uniquing >> sounds awesome. I'm guessing you achieve this by extracting types out of

On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sharing this. Mostly seems like a reasonable plan to me. A few > comments below. > > Thanks Peter! > On Tue, Mar 29, 2016 at 6:00 PM, Eric Christopher via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi All, >> >> This is something that's been

On Tue, Mar 29, 2016 at 8:11 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Mar 29, 2016 at 7:43 PM, Eric Christopher <echristo at gmail.com> > wrote: > >> >> >> On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> Thanks for sharing this. Mostly seems like a reasonable plan to me.

Definitely having someone who knows both formats well would be an advantage. Dave B might be in the best position to do this, so hopefully he can provide a couple more examples of areas where he has trouble expressing CV information entirely in the backend. Regardless of what everyone ends up deciding on with regards to the front-end / back-discussion, I want to suggest separating the work into

Thanks for sharing this. Mostly seems like a reasonable plan to me. A few comments below. On Tue, Mar 29, 2016 at 6:00 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi All, > > This is something that's been talked about for some time and it's probably > time to propose it. > > The "We" in this document is everyone on the cc line

How will this affect other languages that generate debug info - not that you should care about those, I'm just curious - my Pascal compiler does not generate clang-style AST, and does not use clang at all. I currently have code that in uses DIBuilder directly... -- Mats On 30 March 2016 at 04:15, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > On Tue,

On Tue, Mar 29, 2016 at 7:43 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Thanks for sharing this. Mostly seems like a reasonable plan to me. A few >> comments below. >> >> > Thanks Peter! > > >> On Tue, Mar 29, 2016 at 6:00 PM, Eric

> On Mar 29, 2016, at 11:35 PM, mats petersson via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > How will this affect other languages that generate debug info - not that you should care about those, I'm just curious - my Pascal compiler does not generate clang-style AST, and does not use clang at all. I currently have code that in uses DIBuilder directly... I don’t think that

Skipping a serialization and doing something clever about LTO uniquing sounds awesome. I'm guessing you achieve this by extracting types out of DI metadata and packaging them as lumps-o-DWARF that the back-end can then paste together? Reading between the lines a bit here. Can you share data about how much "pure" types dominate the size of debug info? Or at least the current