search for: __dwarf

...does: gcc.s -> 8943786 llvm.s -> 13424378 gcc.o -> 2055892 llvm.o -> 3044512 Why is 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 |...

...230f4e00).__TEXT.__text > 0x00000009 eh-frame [0x0000000112efccf8-0x0000000112efcd68) 0x00000c90 0x00000070 0x6800000b JIT(0x7fc4230f4e00).__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_abbr...

On Jun 21, 2008, at 2:33 PM, Chris Lattner wrote: > > > $ 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, __te...

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

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/

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

...oded in bits of the instruction and some is encoded in bit fields in relocations. If you try to make an arm .o file larger than 16MB, you start hitting various limits. Not all the limits are enforced by the MC layer, resulting in bad .o files. You could try not having debug info, or moving the __DWARF sections to the end of the file, and you might last longer. But the only sure fix is to keep all .o file under 16MB. The final product can be larger because resolved address are 32-bits and the linker inserts branch islands to let BL instructions branch further. -Nick -------------- next par...

...nstruction and some is encoded in bit fields in relocations. If you try > to make an arm .o file larger than 16MB, you start hitting various limits. > Not all the limits are enforced by the MC layer, resulting in bad .o files. > > > You could try not having debug info, or moving the __DWARF sections to the > end of the file, and you might last longer. But the only sure fix is to > keep all .o file under 16MB. The final product can be larger because > resolved address are 32-bits and the linker inserts branch islands to let > BL instructions branch further. > > -Nic...

CCing Nick Kledzik as I posed this question on IRC and Tim Northover suggested you as a good resource for this. I came across an error due to a scattered relocation offset being larger than 2**24 and I was hoping to find more information on scattered relocations. These are MachO specific, and Ive not been able to find any documentation on them outside of source code. I have a couple of immediate

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

On Fri, Jun 30, 2017 at 5:54 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Problem > ------- > > Instrumentation for PGO and frontend-based coverage places a large amount > of > data in object files, even though the majority of this data is not needed > at > run-time. All the data is needlessly duplicated while generating archives, > and > again while

Problem ------- Instrumentation for PGO and frontend-based coverage places a large amount of data in object files, even though the majority of this data is not needed at run-time. All the data is needlessly duplicated while generating archives, and again while linking. PGO name data is written out into raw profiles by instrumented programs, slowing down the training and code coverage workflows.

Hi Dave, Yep. This is JITLink specific, so we could only have observed it on MachO x86-64 or arm64 until recently. It takes a little bit of poking to get IR to produce a zero-lengh section on MachO, but not much. Jared Wyles recently contributed an initial JITLink ELF implementation, so the fix seems timely -- we might have been about to see more of it. -- Lang. On Fri, Jun 19, 2020 at 4:02 PM