search for: __debug_info

...s this? Lets look at the contents: $ sdiff -w 120 gcc.size llvm.size Segment : 1495968 | Segment : 2211617 Section (__TEXT, __text): 251661 | Section (__TEXT, __text): 290873 Section (__DWARF, __debug_frame): 82752 | Section (__DWARF, __debug_frame): 80240 Section (__DWARF, __debug_info): 671478 | Section (__DWARF, __debug_info): 1240778 Section (__DWARF, __debug_abbrev): 3241 | Section (__DWARF, __debug_abbrev): 1535 Section (__DWARF, __debug_aranges): 48 | Section (__DWARF, __debug_aranges): 0 Section (__DWARF, __debug_macinfo): 0 Section (__DWARF, _...

...> $ sdiff -w 120 gcc.size llvm.size > Segment : 1495968 | Segment : 2211617 > Section (__TEXT, __text): 251661 | Section (__TEXT, __text): > 290873 > Section (__DWARF, __debug_frame): 82752 | Section (__DWARF, > __debug_frame): 80240 > Section (__DWARF, __debug_info): 671478 | Section (__DWARF, > __debug_info): 1240778 > Are you sure the gcc numbers are right? I think these are gcc 4.0 numbers. I got: Section (__TEXT, __text): 254569 Section (__DWARF, __debug_frame): 82612 Section (__DWARF, __debug_info): 841164 Evan ------...

...0f4e00).__TEXT.__eh_frame > 0x00000200 container [0x0000000000000784-0x0000000112efce75)* 0x00000aeb 0x00000160 0x00000000 JIT(0x7fc4230f4e00).__DWARF > 0x00000002 dwarf-info [0x0000000112efcd68-0x0000000112efcdb1) 0x00000aeb 0x00000049 0x02000000 JIT(0x7fc4230f4e00).__DWARF.__debug_info > 0x00000003 dwarf-abbrev [0x00007fc4230f5934-0x00007fc4230f595f) 0x00000b34 0x0000002b 0x02000000 JIT(0x7fc4230f4e00).__DWARF.__debug_abbrev > 0x00000004 dwarf-line [0x0000000112efcdc9-0x0000000112efce75) 0x00000b5f 0x000000ac 0x02000000 JIT(0x7fc4230f4e00).__DWARF.__debug_li...

I didn't get to work on this more last week, but I'll look at incorporating that suggestion. The other question of course is how to do this in LLDB. Right, now what I'm doing is going through and adjusting the load address of every leaf in the section tree. That basically works and gets me backtraces with the correct function names and the ability to set breakpoints at functions in

...le. My code flow is: LLVM API -> Assembly file .s -> gcc to .dylib I'm using DIFactory to generate the debug info, and my usage seems to match what clang's CGDebugInfo would do. In my resulting assembly file, I see the DWARF sections with apparently valid data: .section __DWARF,__debug_info,regular,debug etc. As soon as I send my assembly to gcc it disappears. I can call 'as' directly as gcc does, and at this point the debug info disappears: as -g -arch i386 -force_cpusubtype_ALL -o random.o random.s Am I missing a step or not doing something properly to keep my debug i...

On Thu, 26 Jun 2008, Evan Cheng wrote: > Are you sure the gcc numbers are right? I think these are gcc 4.0 numbers. I > got: > > Section (__TEXT, __text): 254569 > Section (__DWARF, __debug_frame): 82612 > Section (__DWARF, __debug_info): 841164 It is entirely possible they are 4.0 numbers, sorry I don't recall... -Chris -- http://nondot.org/sabre/ http://llvm.org/

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

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