similar to: [LLVMdev] __eh_frame info changes in Clang?

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Rafael Espíndola > Sent: Monday, April 27, 2015 2:07 PM > To: Jack Howarth > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] __eh_frame info changes in Clang? > > That looks like a bug. > > From > >

On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > > On 01 Sep 2010, at 08:47, Talin wrote: > > > Once again, I have no idea what this means or how to go about > > debugging it. > > This is my biggest frustration with DIFactory - there's absolutely > > no way to > > verify that the DWARF debugging information that

On 01 Sep 2010, at 08:47, Talin wrote: > Once again, I have no idea what this means or how to go about > debugging it. > This is my biggest frustration with DIFactory - there's absolutely > no way to > verify that the DWARF debugging information that I've emitted into > my module > is correct or even sensible. The only way to test it is to try and > debug

On Sat, Aug 28, 2010 at 10:58 PM, Talin <viridia at gmail.com> wrote: > On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > >> On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: >> >>> >>> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: >>> >>>> I

On Wed, Sep 1, 2010 at 8:31 AM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > >> >> On 01 Sep 2010, at 08:47, Talin wrote: >> >> > Once again, I have no idea what this means or how to go about >> > debugging it. >> > This is my biggest frustration with

I hate to be a nag, but after several days of working on this I am still utterly stumped. Let me recap the situation as it currently stands: I'm trying to write code that generates DWARF debugging information for my compiler using DIFactory and friends. Unfortunately the information I am generating appears to be invalid, but I can't figure out the cause. Based on the advice in the

Hi Rafael, I've been staring at the CFI directives and have a question. Some background: I want to generate the compact unwind information using just the CFI directives. I *think* that this should be doable. The issue I'm facing right now is that I need to know how much the stack pointer was adjusted. So when I have something like this: .cfi_startproc Lfunc_begin175:

On 5 September 2013 19:27, Bill Wendling <wendling at apple.com> wrote: > Hi Rafael, > > I've been staring at the CFI directives and have a question. Some background: I want to generate the compact unwind information using just the CFI directives. I *think* that this should be doable. The issue I'm facing right now is that I need to know how much the stack pointer was

I would like to grow llvm-dwarfdump to become a drop-in replacement for the dwarfdump utility that is currently shipping on Darwin. (You can search the web for "darwin dwarfdump manpage" to see the currently supported feature set.) Doing this means implementing the missing features, such as the ability to print only subsets of DIEs, looking up DIEs by name or address, and the option to

******************** FAIL: LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s (38881 of 41794) ******************** TEST 'LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s' FAILED ******************** Script: -- /home/csabaraduly/wk/LLVM/build_release/bin/llvm-mc -triple x86_64-pc-linux /home/csabaraduly/wk/LLVM/llvm/test/tools/llvm-dwarfdump/X86/debug-names-find.s -filetype=obj -o

Hello Csaba, Thanks for the heads up. I am the one who wrote that test. I'll look into that shortly. Sorry about the trouble. pl On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ******************** > FAIL: LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s (38881 of 41794) > ******************** TEST 'LLVM :: >

r330121 should fix that. Let me know if you still run into any issues. cheers, pl On Mon, 16 Apr 2018 at 12:07, Pavel Labath <labath at google.com> wrote: > Hello Csaba, > Thanks for the heads up. I am the one who wrote that test. I'll look into > that shortly. Sorry about the trouble. > pl > On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < > llvm-dev at

On Fri, Sep 8, 2017 at 2:32 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Fri, Sep 8, 2017 at 2:25 PM Adrian Prantl <aprantl at apple.com> wrote: >> >> I would like to grow llvm-dwarfdump to become a drop-in replacement for >> the dwarfdump utility that is currently shipping on Darwin. (You can search >> the web for

Hi All, I see that llvm-readobj displays information similar to GNU readelf does except DWARF data. I also see llvm-dwarfdump dumps all DWARF data in user readable format. Is there a plan for readobj to incorporate similar options? This will make readobj more feature complete for reading objects similar to readelf. If this is not the plan, will llvm-dwarfdump be a tool that regular user

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

On Feb 11, 2013, at 18:13, Eli Bendersky <eliben at google.com> wrote: > On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: >> Hi, >> >> I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory

>> > I'm fine with this as long as llvm-dwarfdump gets maintained. >> > >> >> I agree, and as I said in the original email, in the long term I >> believe llvm-dwarfdump is the correct solution. >> > > The problem is that if no one is working on testing these sorts of things > with llvm-dwarfdump then it won't be maintained for this

Hi, [ I think I put the most important contributors to the DebugInfo stuff in Cc:. Is there anyone else that I am missing? ] Just a short notice that I am currently working on making llvm-dwarfdump more developer friendly. There are quite a few features in Darwin’s dwarfdump that we find quite useful and that we would like to contribute to llvm-dwarfdump. I have started by augmenting the

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