search for: mcdwarf

In llvm/lib/MC/MCDwarf.cpp's EmitGenDwarfAbbrev(), the DWARF abbreviation declaration for a DW_TAG_label includes a DW_AT_prototyped attribute, but the DWARF 4 specification indicates that the DW_AT_prototyped attribute is not a valid attribute for the DW_TAG_label debug information entry (DIE). In this case, EmitGen...

> On 2014-Jul-15, at 11:07, Reid Kleckner <rnk at google.com> wrote: > > Can we explicitly delete the erase method or do something else to document the fact that it is unsupported? It was added incidentally in r211350, even though it was added and removed by Doug back in r175538 / r175449. > I'm happy with it deleted or fixed (see WIP patch that fixes it w/o tests). For

...X where __register_frame takes a > single FDE at a time. I have an incomplete wip patch if you are > interested. On BSD __register_frame also takes a single argument and therefore needs terminating zero. I also have a simple patch for this: adding Streamer.EmitIntValue(0, 4); at the end of MCDwarfFrameEmitter::Emit in lib/MC/MCDwarf.cpp fixed the issue for me. Somebody needs to check this or similar in. Yuri

...lvm.org > Subject: Re: [llvm-dev] Potential DWARF debug info bug: DW_TAG_label DIE > has a DW_AT_prototyped attribute > > > > > On Jan 18, 2019, at 1:06 PM, Snider, Todd via llvm-dev <llvm- > dev at lists.llvm.org> wrote: > > > > > > In llvm/lib/MC/MCDwarf.cpp’s EmitGenDwarfAbbrev(), the DWARF > abbreviation declaration for a DW_TAG_label includes a DW_AT_prototyped > attribute, but the DWARF 4 specification indicates that the > DW_AT_prototyped attribute is not a valid attribute for the DW_TAG_label > debug information entry (DIE). In th...

Hi Oliver, There would be no problem if both the Map and the Vector indeed contained (Key,Value) pairs. To save space, Map entries do not contain Value but instead an unsigned index into the Vector: /// The values are kept in a std::vector and the /// mapping is done with DenseMap from Keys to indexes in that vector. After an element is erased from the Vector all indices greater than the

> On 2014-Jul-15, at 09:38, David Blaikie <dblaikie at gmail.com> wrote: > > On Tue, Jul 15, 2014 at 9:31 AM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >>> On 2014-Jul-15, at 08:29, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> Sounds pretty clearly buggy, and against the original design of the

...ifference)) > > If you're happy to fix/test a MapVector::remove_if, that'd be swell. > It might be a while before I find the time to refactor this whole > thing into something common (& /maybe/ in the process, avoid this > particular removal quirk) between DwarfDebug and MCDwarf... :/ > > - David Here's a patch with the fixes (totally untested). I'll commit incrementally as I write unit tests, but you can use this locally if you want to try out changes to the MC code in the meantime. +chandlerc: as code owner of ADT, any problem with me adding this API to...

...ode (both gone now). Moreover, if we ignore the lazy evaluation mechanism then the current JIT is actually quite simple module. Would it be possible to keep such barebones JIT (without lazy evaluation which does add to the complexity) and get back the Debug and EH information but from the existing MCDwarf framework ? What were the reasons EH and Debug modules were duplicated in JIT rather then reused from lib/MC? Maybe move the barebones JIT function-level functionality (stub functions) into MCJIT ? Yaron 2013/10/30 Jim Grosbach <grosbach at apple.com> > Sure, that makes a lot of se...

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191127/dc214059/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201911271044539_EW9BEWXX Type: application/octet-stream Size: 13168 bytes Desc: not available URL:

> The problem with this is that __register_frame function (in libgcc_s.so), > registering .eh_frame with an exception handler, only takes the pointer to > .eh_frame, and not the size of data, and should be able to detect the end of > data by scanning it and hitting zero DWORD (size). There is no trailing > zero, and it runs into the next section and tries to interpret it as an >

Please look at the fragment of the hex dump of LLVM-created ELF showing the beginning and end of .eh_frame: .eh_frame begin 000297a0 14 00 00 00 00 00 00 00 01 7a 52 00 01 78 10 01 |.........zR..x..| 000297b0 1b 0c 07 08 90 01 00 00 18 00 00 00 1c 00 00 00 |................| <...skipped...> 0002cb00 00 00 00 00 0b 01 00 00 00 41 0e 10 86 02 43 0d |.........A....C.| 0002cb10 06 42

Sure, that makes a lot of sense. The implementation details may get tricky, of course, but the concept is great. -Jim On Oct 30, 2013, at 12:20 PM, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > I'm trying to transition from the JIT to MCJIT. The requirements are fast response time and dynamic unloading/replacement of modified functions. Lazy evaluation is *not*

Hi, I'm trying to transition from the JIT to MCJIT. The requirements are fast response time and dynamic unloading/replacement of modified functions. Lazy evaluation is *not* required: I expect all functions to be present at runtime or else an error is fine. With the JIT it's quite simple to unload and replace functions due to the stubs (JMP instructions) that redirect the actual function

...Kleckner <rnk at google.com> wrote: > The gen-dwarf* test failures actually seem like an MSVC compiler bug. This > variable somehow gets folded to true with MSVC, and extra unexpected > relocations are produced: > > https://github.com/llvm/llvm-project/blob/master/llvm/lib/MC/MCDwarf.cpp#L1141 > > I will try to reduce it. I suspect it requires this specific MSVC release > to reproduce, and our buildbots must not have it. > > On Tue, Jan 21, 2020 at 4:39 PM Alexandre Ganea via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >...

Hi, A few tests seem broken for a long time, some for more than a month. Would it possible for respective owners to take a look please? I'm at checkout 133a7e631cee97965e310f0d110739217427fd3d, compiling on Windows 10. These tests fail with Visual Studio 2019: Failing Tests (7): Clang Tools :: clang-tidy/checkers/cert-mem57-cpp-cpp17.cpp Clang Tools ::

.../usr/local/llvm-2.8/include/llvm/MC/MCCodeEmitter.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCContext.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCDirectives.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCDisassembler.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCDwarf.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCELFSymbolFlags.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCExpr.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCFixup.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCInst.h -- Installing: /usr/local/llvm-2.8/include/llv...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel

...cpp for Release+Asserts build llvm[2]: Compiling ObjectFile.cpp for Release+Asserts build llvm[2]: Compiling LiveRegMatrix.cpp for Release+Asserts build llvm[3]: Compiling DWARFDebugLine.cpp for Release+Asserts build llvm[2]: Compiling RecordStreamer.cpp for Release+Asserts build llvm[2]: Compiling MCDwarf.cpp for Release+Asserts build llvm[2]: Compiling SymbolSize.cpp for Release+Asserts build llvm[3]: Compiling DWARFDebugLoc.cpp for Release+Asserts build llvm[2]: Compiling LiveStackAnalysis.cpp for Release+Asserts build llvm[2]: Compiling MCELFObjectTargetWriter.cpp for Release+Asserts build llvm[2...