similar to: [yaml2obj] GSoC-20: Add DWARF support to yaml2obj

On 31/03/2020 18:29, Adrian Prantl via llvm-dev wrote: > It's great to see someone interested in improving yaml2obj! > > As far as I'm concerned, the main problem with yam2obj for DWARF testcases is that at the moment, it is both too high-level and too low-level at the same time. For writing debug info testcases, yaml2obj at the moment does not add anything on top of assembler.

On 5/21/20, Adrian Prantl <aprantl at apple.com> wrote: > I think the example looks like it would be really useful for many categories > of testcases! > Will it still be possible to manually specify the .debug_abbrev section when > this is desired after you are done? Yes, I think it works. There are two ways to edit the .debug_abbrev section. i) Edit the "Attr:" and

I believe the compiler will generate a .debug_ranges section if you use -ffunction-sections, since the addresses of sections will be non-contiguous. From there, you should be able to edit the .debug_ranges assembly as needed (replace references to symbols with 0s in the .debug_ranges content) to get the exact behaviour you want (I'm assuming you don't want to have to hand-edit a

Hi folks, I am going to implement DWARF support for yaml2obj. I really appreciate it that many of you have given me a lot of useful comments and suggestions in the previous thread [1]. I've had some offline discussions with James and done some updates to the previous proposal. This proposal addresses the issue of properly describing the DWARF sections in YAML both at a high level and at a

(Reviving this thread because a code review reminded me I want to reply here. Sorry for the extremely long turnaround). On 31/03/2020 20:22, Fangrui Song wrote: > On 2020-03-31, Adrian Prantl via llvm-dev wrote: >> >> >>> On Mar 31, 2020, at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> +1 to all that & cc'ing a few of the

> On Mar 31, 2020, at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote: > > +1 to all that & cc'ing a few of the usual suspects as FYI > > On Tue, Mar 31, 2020 at 10:36 AM Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > For me personally, the ability to write/edit syntactically

Hi Pavel, Thanks for your comments! On 5/21/20, Pavel Labath <pavel at labath.sk> wrote: > Hello Xing, > > I think the proposal looks very useful. I think it will be fairly tricky > to get all of the details right though. There is a lot of "inferring" > going on there, and getting that to work reliably and with predictable > results will need careful

I think we have to be careful here. We might want flexibility to say "I want to use a specific class" without having to specify the exact DW_FORM. Sometimes, we might even end up in an ambiguous situation and not get the result we want. For example, in DWARFv4, the DW_AT_high_pc attribute has either a Constant or an Address class, which use completely different forms, but if we have just

Hello DWARF fans, I've just posted a set of four refactoring patches for DebugInfo/DWARF, which move in the direction of handling DWARF v4 or v5 type units and compile units more coherently. In DWARF v4, type units and compile units are strictly segregated into the .debug_types and .debug_info sections, respectively. This division was pretty ingrained into how DebugInfo/DWARF handled the

On Mar 29, 2011, at 7:29 PM, Talin wrote: > I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: > > gdb stack crawl at point of internal error: > [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin

I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: gdb stack crawl at point of internal error: [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300] [ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin

> On Apr 27, 2017, at 8:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > > This'll need a test case, in any case. In case you're wondering, one way to do this would be to add an assembler source file, compile it and run it through llvm-dwarfdump. Alternatively you can use the new yaml2obj tool that is being developed. -- adrian > > Adrian/Paul: Pondering

Hi DebugInfo folks, I have a question on using fsplit-dwarf-inlining option: "-fsplit-dwarf-inlining, -fno-split-dwarf-inlining Provide minimal debug info in the object/executable to facilitate online symbolication/stack traces in the absence of .dwo/.dwp files when using Split DWARF" i.e. it puts some debug info into compilation unit from First partition(with Skeleton unit). At

On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 29, 2011, at 7:29 PM, Talin wrote: > > I've been trying to track down the problem with the DWARF info that is > being emitted by my front end, which has been broken for about a month now. > Here's what happens when I attempt to use gdb to debug one of my programs on > OS X:

Thanks for providing the experimental data! It clearly shows the value of type sections in DWARF. Regarding why type sections are off by default, aside from the issue of consumers needing to understand them, there is a size penalty to type sections that becomes more evident in smaller projects (meaning, fewer compilation units). The size penalty can be balanced against the amount of

Great, thanks! Those results are about roughly what I was expecting. I assume "compilation time" is actually just the link time? I find it particularly interesting that the DWARFLinker rewriting solution produces the same size improvement in .debug_line as the fragmented DWARF approach. That suggests that in that case, fragmented DWARF output is probably about as optimal as it can get.

hi Devang and thanks for the tips, i finally managed to fit all the pieces together into something that seems to work. It's probably not the best (or even correct!) way of doing it but here's a brief overview for reference: An instruction in the LLVM IR gets converted into an SDNode in the DAG then later into a MachineInstr. I'd already attached my own MDNodes to IR instructions I

Hi Roger, On Mon, Aug 23, 2010 at 4:01 PM, Roger Wang <innit42 at gmail.com> wrote: > Dear all, > > I'd like to find the memory location of certain instructions in a > compiled/linked binary. During the IR phase, I tag instructions I'm > interested in with LLVM'-2.7's new metadata (MDNodes with an identifiable > ID). I'd now like to propagate that data

Dear all, I'd like to find the memory location of certain instructions in a compiled/linked binary. During the IR phase, I tag instructions I'm interested in with LLVM'-2.7's new metadata (MDNodes with an identifiable ID). I'd now like to propagate that data to the assembly via a custom DWARF tag I attach to each X86 instruction created from a tagged IR instruction. This will

Hi folks, I am trying to implement the C bindings API for DebugInfo::DWARF::DWARFDie. My goal is to have a C library that reads and parses DWARF debugging format (just like how llvm-dwarfdump does, but maybe more than just dumping debug info) I've started with creating C structure for DebugInfo::DWARF::DWARFContext which contains all DWARF DIEs in the object file. For this I used ```