similar to: [LLVMdev] Debug information on multiple files

See "DwarfDebug problem with line section" thread on llvmdev. Bottom line, we may need a target specific patch for targets that do not follow dwarf standard (as per my reading) in this particular case. - Devang On Wed, Aug 25, 2010 at 5:49 AM, Renato Golin <rengolin at systemcall.org>wrote: > Hi, > > I'm trying to compile two files together with debug information

On 25 August 2010 18:54, Devang Patel <devang.patel at gmail.com> wrote: > See "DwarfDebug problem with line section" thread on llvmdev. Bottom line, > we may need a target specific patch for targets that do not follow dwarf > standard (as per my reading) in this particular case. Hi Devang, Ok, got the background, but will reply on this email. As far as I understood,

Much like the recent efforts to provide a port of dsymutil in the LLVM project, I'm looking at providing an implementation of the Fission/Split DWARF DWP tool ( https://gcc.gnu.org/wiki/DebugFissionDWP ) in LLVM. While there's potentially some overlap between the two tools, I'm thinking of keeping them separate at least initially since much of the debug info doesn't need to be

On Tue, Nov 3, 2015 at 5:06 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > SGTM. This will bring us closer to the point when we can write tests, > where we strip out the .dwo files from executables, package them together > with llvm-dwp, and then verify that we still get all we need from > llvm-symbolizer. > Not quite following here - dwo sections are already stripped

I've also been looking at debugging with ELF and noticed the same problem as Renato. I just sent a patch to llvmcommits that fixes the problem. DW_at_stmt_list needs to emit a label(and therefore a relocation) for the offset rather a constant 0, then the linker can fixup the offset as it shuffles object files around. Krister On Thu, Aug 26, 2010 at 5:11 AM, Renato Golin <rengolin at

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

I have a PSTN termination provider "foo" which will accept standard U.S. calls in the form 1<10 digit ph#>. I have an outbound route named "foo", with dial pattern "5|.", with the only entry in trunk sequence being "IAX2/foo". I have an X-lite local extension, on which I can dial 51<10 digit ph#>, and asterisk will call out over foo and the

On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: >> > >> > >> > >> > > -----Original Message-----

On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Nagaraju > > Mekala via llvm-dev > > Sent: Tuesday, April 21, 2020 6:04 AM > > To: jh7370.2008 at my.bristol.ac.uk > > Cc: LLVM Developers Mailing List

(Adding back Cc: which got dropped) > (Igor - I don't know what happened, but your email split the mail thread in gmail for me.) The problem is that https://lists.llvm.org/pipermail/llvm-dev/2020-November/146528.html does not have an In-Reply-To: header. Added Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer

On 2020-05-28, David Blaikie wrote: >On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com> >wrote: > >> As has been mentioned elsewhere, Sony generally fixes up references from >> debug info to stripped functions (of any length) using -1, because that’s a >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base >>

Hi James, Thanks for reply. When I looked in to the generated debug dump from the object file I found that DW_AT_name is always (indirect string, offset: 0x0): clang version 8.0.1, instead of variable names. Below is a sample output of the debug dump. Compilation Unit @ offset 0x0: Length: 0x6a (32-bit) Version: 4 Abbrev Offset: 0x0 Pointer Size: 4

On 30 Jun 2010, at 18:40, Devang Patel wrote: > On Wed, Jun 30, 2010 at 1:57 AM, Artur Pietrek <pietreka at gmail.com> > wrote: >> The problem is that you put difference between two labels >> .Lset7 = .Lsection_line_begin-.Lsection_line ## DW_AT_stmt_list >> and that will be evaluated by assembler to a constant. It has to be >> a label, >> not a

On Tue, Aug 17, 2010 at 7:09 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > > On ELF platforms (at least Linux and FreeBSD) and on Windows, both of > the following are labels (i.e., absolute addresses to be relocated by > the linker) as opposed to offsets relative to the relevant section's > start, even though the DWARF standard says they are offsets: > *

Dear LLVM devs, I've noticed that LLVM's assembler (and hence clang) doesn't generate debug data when assembling, even when run with "-g". Users can add their own CFI/line number data with assembler directives. But GDB ignores the line number data if you don't have a DIE in the .debug_info section which identifies the compilation unit. (I'm not an expert on GDB, but

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

Hi, On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> wrote: >> As far as I understand now it is impossible to generate ELF object >> file with relocation sections using yaml2obj tool. I plan to support >> ELF relocations in the yaml2obj. Does anybody work

On Fri, May 29, 2020 at 9:21 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: Fangrui Song <maskray at google.com> > > Sent: Friday, May 29, 2020 1:07 AM > > To: David Blaikie <dblaikie at gmail.com> > > Cc: Robinson, Paul <paul.robinson at sony.com>; Alexey Lapshin > >

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

On Fri, May 29, 2020 at 2:20 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Friday, May 29, 2020 5:00 PM > > To: Robinson, Paul <paul.robinson at sony.com> > > Cc: Fangrui Song <maskray at google.com>; Alexey Lapshin > >