similar to: [LLVMdev] [patch] Dwarf Debug info support for COFF object files

On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > Hello All, > > I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final

On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > > On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > >> Hello All, >> >> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run

On Feb 24, 2011, at 11:52 AM, Devang Patel wrote: > > On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > >> >> On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: >> >>> Hello All, >>> >>> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a

Pete Cooper and I have been looking at memory profiles of running llc on verify-uselistorder.lto.opt.bc (ld -save-temps dump just before CodeGen of building verify-uselistorder with -flto -g). I've attached leak-backend.patch, which we're using to make Intrustruments more accurate (instead of effectively leaking things onto BumpPtrAllocators, really leak them with malloc()). (I've

With just those four patches, memory usage went *up* slightly. Add in the 5th patch (which does #2 below), and we get an overall memory drop of 4%. The intermediate result of a memory increase makes sense. While the first four patches reduce the number of (and size of) `DIEValue` allocations, they increase the cost of the `SmallVector` overhead. 0005 (attached) squeezes the abbreviation data

> On 2015 May 20, at 17:51, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > >> On 2015 May 20, at 17:39, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >> With just those four patches, memory usage went *up* slightly. Add in >> the 5th patch (which does #2 below), and we get an overall memory drop >> of 4%. > >

I have updated my patch based on Chris'es feedback. I removed the dbgout_calls macro, but left others in place for now. If there are no objections, I would like to commit this tomorrow evening (~7PM GMT-7). I have compiled and tested it on MSVC, with Michaels testing code and it looks good. Once this is committed, Michaels patch can be applied. -Nathan -------------- next part --------------

On Mon, Jun 21, 2010 at 9:37 AM, Aaron Gray <aaronngray.lists at gmail.com> wrote: > > Whats going on with having both write_uint32_le() > in WinCOFFObjectWriter::DefineSection() and WriteLE32() in > WinCOFFObjectWriter::WriteFileHeader() ? > Aaron Thanks, missed that one. Nathan used write_uint32_le in WinCOFF.h, and I guess accidentally used it in WinCOFFObjectWriter.cpp.

Hi all, We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and we've found that one of the top consumers of memory is the DWARF emitter in lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code and I have a few ideas in mind for how to reduce its memory consumption. One idea I've had is to restructure the emitter so that (for the most part) it

Hi Nathan, I'm not quite ready to apply this patch, but I now have time again to work on getting it in. The main reason I am not willing to put it in yet is (a) the size, and (b) the inconsistences with LLVM style. Please fix the following things: - Watch out for case mismatches, i.e., #include "WinCoff.h" when the header is actually WinCOFF.h. - The patch doesn't have a

On Mon, Jun 21, 2010 at 3:15 PM, Nathan Jeffords <blunted2night at gmail.com> wrote: > write_uint32_le is used to write into a arbitrary data buffer, where as >  WriteLE32 is used to write into the object file. Ah, I didn't notice that. Here's yet another style patch. Thanks to coppro for the review that found most of these. (note, I made a branch and did a rebase just so I

Hello, LLVM currently supports emission of CodeView's line table subsection. However, we'd like to increase the fidelity of this debug info with column information. I was wondering if anybody had any pointers as to how CodeView represents such information. Thanks! -- David Majnemer -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, As a first step to port the LLVM chain on an in-house big-endian processor, I'm integrating the native assembler as a new '-assemble -arch=' in llvm-mc. All work quite well, I have a correct output ELF format except that generated code is little-endian. I've understood that the endianess of the LLVM chain is controlled by the DataLayout class, but it appear to me that llvm-mc

write_uint32_le is used to write into a arbitrary data buffer, where as WriteLE32 is used to write into the object file. On Mon, Jun 21, 2010 at 9:01 AM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Mon, Jun 21, 2010 at 9:37 AM, Aaron Gray <aaronngray.lists at gmail.com> > wrote: > > > > Whats going on with having both write_uint32_le() > > in

Thanks, I'll look into that. (Though earlier you told me that debug info for types could be extended while walking the IR, so I wouldn't have thought that would have worked.) Peter On Fri, Feb 05, 2016 at 03:52:19PM -0800, David Blaikie wrote: > Will look more closely soon - but I'd really try just writing out type > units to MC as soon as they're done. It should be

On 28 May 2010 05:59, Nathan Jeffords <blunted2night at gmail.com> wrote: > For those that are interested, I have attached the latest version of my > Win32 COFF support patch. There is no new functionality, I just fixed some > compiler errors due to recent changes in the MC library. > > Nathan, Sorry about this but... On Cygwin with GCC-4.2.4 :- In file included from

Right on, thanks for working on this. I have been busy lately, but its good to see progress being made. On Mon, Jun 21, 2010 at 11:31 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Mon, Jun 21, 2010 at 3:15 PM, Nathan Jeffords > <blunted2night at gmail.com> wrote: > > write_uint32_le is used to write into a arbitrary data buffer, where as > > WriteLE32

On Jun 19, 2011, at 3:20 PM, Nathan Jeffords wrote: > As it happens, I have created a patch that enables DWARF debugging on windows. It is against trunk revision 133401. I have tested using clang to compile, and mingw to link & debug. +#include "../Target/X86/X86FixupKinds.h" This indicates layering violation to me. It looks good otherwise. Do you have a testcase ? LGTM.

Hi, I'm in the process of adding a X86 ASM Printer for outputting the asm in a style that Yasm can take without any post processing. Yasm's format is very close to that of intel. I was wondering if my approach is correct: I've made a custom MCAsmStreamer to remove some of the COFF symbol directives that yasm doesn't understand. I've made a X86YasmInstPrinter, and added it

Here is a full patch including Nathan's COFF support, tests that pass on Windows, and some changes to lit. Obviously the COFF support and changes to lit should be separate patches in the end. http://codereview.appspot.com/1624043/show - Michael Spencer -------------- next part -------------- A non-text attachment was scrubbed... Name: COFF-support.patch Type: application/octet-stream Size: