similar to: llvm bug 36466 fix

Hi Dave I am not going to access any hardware. I am using clang to analysis the ARM binaries. The binary is 483.xalancbmk in CPU SPEC2006. When I use the optimization O0, no crash will occur. The crash occurs when I set optimization level as O1,O2,O3 and Os. If I have to recompile and rerun the tests. What version of llvm is suggested. It would be better if anyone could provide the patch on this

Hi Dave Sorry, I meant the hardware you're using to compile LLVM - you mentioned it took you a long time to rebuild it so it would be hard for you to write/experiment on tests. ============================= Compiling LLVM doesn't take me too much time(less than 2 hours). The hardware is good enough and I am using interl E5 CPU. What I mean is that it took me a long time to analysis the

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 ```

Hi David, Sorry, I forget to attach the valgrind dump to this. I was not sure if my implementation was ok, so I wanted to ask if I've done something wrong first. Process terminating with default action of signal 11 (SIGSEGV) Access not within mapped region at address 0xB at 0x54F4516: llvm::object::COFFObjectFile::moveSectionNext(llvm::object::DataRefImpl&) const

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 ::

Hi Frédéric and LLVM, I managed to finally come back to this after quite a while. Frédéric, thank you very much for the pointer to your work; it’s saving me a lot of time! Unfortunately, I am running into one issue that my knowledge isn’t complete enough to solve on my own yet. The description of D6771 reads, "It requires a few preliminary patches like landing D6243 and adding a

Hi, This is my first post to this list, so I apologize in advance if I mess up on any list etiquette. Jumping right in, I’m making use of the DebugInfo/DWARF APIs to get debugging information out of binaries (what else!). One of the bits of data I need is the location information stored in the location list section as well as inline in DW_AT_location attributes and similar. So far I’ve succeeded

So, for this test case: extern "C" void shouldBeUnconditional(); extern "C" void shouldBeConditional(); extern "C" void otherCall(); void testFn(bool Bool1, bool Bool2) { Bool1 |= Bool2; shouldBeUnconditional(); if (Bool1) shouldBeConditional(); if (Bool2) { otherCall(); if (Bool1) otherCall(); } } MSVC generates this buggy asm: $ cl -c

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to work and also validate the changes that I am making. There are not many DWARF unit tests other than very simple ones that test DWARF forms currently. I would like to expand this to include many more tests. I had

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

On 06.11.2020 13:32, James Henderson wrote: > Hi Alexey, > > On Thu, 5 Nov 2020 at 21:02, Alexey Lapshin <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > Hi James, > > On 05.11.2020 17:59, James Henderson wrote: >> (Resending with history trimmed to avoid it getting stuck in >> moderator queue). >>

> On Nov 17, 2016, at 3:40 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 17, 2016 at 3:12 PM Greg Clayton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to

I am looking to create a tool that can add Apple or DWARF5 accelerator tables to fully linked executables that contain DWARF. This will help us benchmark how much accelerator tables can improve the debugging experience as debuggers don't need to manually index all of the debug info during debugging. Looking at how accelerator tables are currently emitted, they seem to be built up as DWARF is

> On Nov 17, 2016, at 5:40 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > > > >> -----Original Message----- >> From: Greg Clayton [mailto:gclayton at apple.com] >> Sent: Thursday, November 17, 2016 5:01 PM >> To: David Blaikie >> Cc: llvm-dev at lists.llvm.org; Robinson, Paul; Eric Christopher; Adrian >> Prantl >> Subject: Re:

llvm[2]: Compiling DWARFDebugArangeSet.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugAranges.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugFrame.cpp for Debug+Asserts build /home/rkotler/llvm_trunk/lib/DebugInfo/DWARFDebugFrame.cpp:118:8: error: private field 'LinkedCIE' is not used [-Werror,-Wunused-private-field] CIE *LinkedCIE; ^ 1 error

> On Feb 28, 2020, at 11:25 PM, Fangrui Song via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 2020-02-28, Greg Clayton via llvm-dev wrote: >> I am looking to create a tool that can add Apple or DWARF5 accelerator tables to fully linked executables that contain DWARF. This will help us benchmark how much accelerator tables can improve the debugging experience as

Which seems like what we'd want dsymutil to do anyhow? -eric On Mon, Mar 2, 2020 at 3:21 PM Greg Clayton via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On other options would be to make a new "llvm-dwarfld" tool, where most of > the functionality would exist llvm/lib/DwarfLinker and other locations. The > idea would be to do any post processing to DWARF using

I'd like it... Adrian? Fred? -eric On Mon, Mar 2, 2020 at 3:44 PM Greg Clayton <clayborg at gmail.com> wrote: > Yes. I am fine with adding ELF support to llvm-dsymutil if that is the way > people think we should go? > > On Mar 2, 2020, at 3:33 PM, Eric Christopher <echristo at gmail.com> wrote: > > Which seems like what we'd want dsymutil to do anyhow? >

On Fri, Nov 18, 2016 at 10:18 AM Eric Christopher <echristo at gmail.com> wrote: > On Fri, Nov 18, 2016 at 8:43 AM Greg Clayton <gclayton at apple.com> wrote: > > > > On Nov 17, 2016, at 5:40 PM, Robinson, Paul <paul.robinson at sony.com> > wrote: > > > > > > > >> -----Original Message----- > >> From: Greg Clayton