similar to: Implementation of DWARF expression parser

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

Hello, I'm trying to fix a long standing issue we are having in Julia where when the file information switched, we weren't recording that correctly, so line information showed up in the wrong file. Basically we would always create a scope with the DISubprogram and the given line number. What I tried was to change the scope to be a DIFile instead so we'd get the correct file

Hi, I am looking for a way to get unmangled subprogram names from a DWARFContext. The name I want is available in the attribute `DW_AT_name` [1], but as far as I can tell this is only returned as a fallback in `DWARFDebugInfoEntryMinimal::getSubroutineName` when the linkage name is not available [2]. If this is not currently possible, is there any interest in adding such access to the public

Sorry, I didn't have a small IR example and I was sure I was just doing something stupid. Thanks for the help, I'll try it out and report back. Maybe it would be good to add an assertion or something that tells people what's wrong in this case, since the generated DWARF seems to be invalid? On Wed, Aug 13, 2014 at 5:53 PM, David Blaikie <dblaikie at gmail.com> wrote: > Use

That doesn't seem possible with the public API or am I mistaking? On Wed, May 7, 2014 at 12:13 AM, Eric Christopher <echristo at gmail.com>wrote: > On Tue, May 6, 2014 at 8:09 PM, Isaiah Norton <isaiah.norton at gmail.com> > wrote: > > Hi, > > > > I am looking for a way to get unmangled subprogram names from a > > DWARFContext. The name I want is

Oh, I see. Sorry I misunderstood. I'll try to come up with some minimal IR. The assertion stems from the fact that getCompileUnitDIE() returns null and then crashes at DWARFUnit.cpp:301. I admit I don't know if this problem is on the parsing or the generation side. While I come up with the IR, basically what I was doing was using a DebugLoc with scope being a DIFile rather than a

The use case is getting the short name for backtraces. There are other options, but I figured it was worth a shot trying to access from the DWARF structure because what we need is already stored there anyway. Thanks, Isaiah On Wed, May 7, 2014 at 12:24 PM, Alexey Samsonov <samsonov at google.com>wrote: > Yeah, public API of DebugInfo library is quite minimalistic. But I agree >

On Wed, May 7, 2014 at 11:33 AM, Eric Christopher <echristo at gmail.com>wrote: > Have you checked out llvm-symbolize? It's what the asan folk > (including Alexey) have created for backtrace symbolication. > Yeah, we potentially can add some kind of option: "llvm-symbolizer -print-short-function-names", I don't yet see why this would be valuable. What's wrong

Hi I come across the following exception when I use the llvm-dwarfdump -debug-info target_binary: llvm-dwarfdump: /home/linux/llvm-7/llvm/lib/MC/MCRegisterInfo.cpp:87: int llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool) const: Assertion `I != M+Size && I->FromReg == RegNum && "Invalid RegNum"' failed. Stack dump: 0. Program arguments:

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

On Wed, May 7, 2014 at 11:38 AM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The use case for this is in Julia backtraces. We don't have a consistent > way to mangle the function names for linkage (we might at some point in the > future, but this is out of scope for now). Instead, we save whatever we > want displayed in AT_name, but there's no way to access

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

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

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