Displaying 5 results from an estimated 5 matches for "__debug_str".
2008 Jun 21
3
[LLVMdev] llvm-gcc -O0 compile times
...line): 126106 | Section (__DWARF,
__debug_line): 149797
Section (__DWARF, __debug_loc): 0 Section (__DWARF, __debug_loc): 0
Section (__DWARF, __debug_pubnames): 168873 | Section (__DWARF,
__debug_pubnames): 165104
Section (__DWARF, __debug_pubtypes): 32449 |
Section (__DWARF, __debug_str): 17541 | Section (__DWARF,
__debug_str): 0
Section (__DWARF, __debug_ranges): 456 | Section (__DWARF,
__debug_ranges): 0
Section (__DATA, __const): 100 | Section (__DATA, __const): 136
Section (__TEXT, __cstring): 11543 | Section (__TEXT,
__cstring): 12678
Section (_...
2014 Jun 02
2
[LLVMdev] [lldb-dev] MCJIT Mach-O JIT debugging
...debug_abbrev
> 0x00000004 dwarf-line [0x0000000112efcdc9-0x0000000112efce75) 0x00000b5f 0x000000ac 0x02000000 JIT(0x7fc4230f4e00).__DWARF.__debug_line
> 0x00000005 dwarf-str [0x00007fc4230f5a0b-0x00007fc4230f5a4b) 0x00000c0b 0x00000040 0x02000000 JIT(0x7fc4230f4e00).__DWARF.__debug_str
> 0x00000006 dwarf-loc 0x00000c4b 0x00000000 0x02000000 JIT(0x7fc4230f4e00).__DWARF.__debug_loc
> 0x00000007 dwarf-ranges 0x00000c4b 0x00000000 0x02000000 JIT(0x7fc4230f4e00).__DWARF.__debug_range...
2014 Jun 02
2
[LLVMdev] [lldb-dev] MCJIT Mach-O JIT debugging
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
2017 Jul 01
4
[RFC] Placing profile name data, and coverage data, outside of object files
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
2017 Jul 01
7
[RFC] Placing profile name data, and coverage data, outside of object files
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.