search for: debug_frame

While comparing debug info between GCC and Clang I found a section that only Clang produces and GCC never produces: debug_frame. It seems (though I haven't verified this with absolute certainty) as though GCC just always uses eh_frame. LLVM on the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with -fno-exceptions -g. The fi...

...r 20, 2014 at 10:41 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 19 March 2014 17:31, David Blaikie <dblaikie at gmail.com> wrote: >> While comparing debug info between GCC and Clang I found a section >> that only Clang produces and GCC never produces: debug_frame. >> >> It seems (though I haven't verified this with absolute certainty) as >> though GCC just always uses eh_frame. LLVM on the other hand sometimes >> uses eh_frame and sometimes uses debug_frame. >> >> Here's an example: >> >> int f1(); &gt...

...[13] .debug_pubtypes PROGBITS 0000000000000000 00001350 [14] .rela.debug_pubty RELA 0000000000000000 00003868 [15] .debug_str PROGBITS 0000000000000000 00001373 [16] .debug_ranges PROGBITS 0000000000000000 000015ff There's no ".debug_frame", although ".eh_frame" was produced. Doesn't Clang/LLVM create the .debug_frame section by default? Thanks in advance, Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111216/5385914a/a...

I'm cross compiling using clang for x86_64 windows using SEH exceptions. If at all possible, I would like to enable unwind tables to be generated in debug_frame, but I was unable to figure out how to accomplish this. Is there a supported way? Thanks, Keno

...ticed 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 constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish patch, or could somebody else fix it, or can I just commit the change to svn? >> > > Please submit a patch to llvm-commits, with a test case that exercises the fix. > > Eli Before I submit the patch,...

...430MCAsmInfo.cpp +++ b/llvm/lib/Target/MSP430/MCTargetDesc/MSP430MCAsmInfo.cpp @@ -24,4 +24,6 @@ MSP430MCAsmInfo::MSP430MCAsmInfo(StringRef TT) { AlignmentIsInBytes = false; UsesELFSectionDirectiveForBSS = true; + + SupportsDebugInformation = true; } does, indeed enable debug - but NOT .debug_frame (and IIRC some of the variable range info goes missing). it needs: diff --git a/llvm/lib/Target/MSP430/MCTargetDesc/MSP430MCAsmInfo.cpp b/llvm/lib/Target/MSP430/MCTargetDesc/MSP430MCAsmInfo.cpp index df1aa1a..e7e0550 100644 --- a/llvm/lib/Target/MSP430/MCTargetDesc/MSP430MCAsmInfo.cpp +++ b/llvm/...

...ticed 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 constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish patch, or could somebody else fix it, or can I just commit the change to svn? -- Erik.

Hi All, We have a local change in the X86AsmPrinter that outputs a section containing metadata on function stack sizes. We use this to measure changes to stack size between versions of the compiler and it also allows our licensees to do the same for their code. The section simply contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128). We would like to

...ation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1. llvm-dwarfdump: the best approach when it works. But unfortunately > lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections > like debug_frame aren't supported. Could you point out what you mean? In particular, what parts you think it does not support (since you say it supports a small subset). What do you want out of debug_frame, past simple parsing? Anything else requires real evaluation. I ask because I wrote a DWARF reader that...

Hi, :If I compile this file with debugging enabled (clang/LLVM TOT) int main() { } I get the error Error: inconsistent uses of .cfi_sections From the 2.27 binutils assemblers. It seems that 2.27 doesn't like the .cfi_sections .debug_frame directive following previous .cfi directives. The assemblers seem to be happy if the .cfi_sections directive precedes any other .cfi directive. Is this a bug in binutils or LLVM? It looks as if a fix might be to move the generation of the .cfi_sections directive from endModule() to somewhere e...

...file format elf64-x86-64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 000000000000005a R_X86_64_PC32 atoi-0x0000000000000004 0000000000000066 R_X86_64_32 .rodata.str1.1 000000000000006f R_X86_64_PC32 printf-0x0000000000000004 RELOCATION RECORDS FOR [.debug_frame]: OFFSET TYPE VALUE 0000000000000018 R_X86_64_32 .debug_frame 000000000000001c R_X86_64_64 .text 0000000000000040 R_X86_64_32 .debug_frame 0000000000000044 R_X86_64_64 .text+0x0000000000000040 RELOCATION RECORDS FOR [.debug_info]: OFFSET T...

...ran into an unpleasant limitation the LLVM eco-system has with testing DWARF emission. We currently have several approaches, neither of which is great: 1. llvm-dwarfdump: the best approach when it works. But unfortunately lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections like debug_frame aren't supported. 2. Relying of assembly directive emissions (i.e. .cfi_*), which is cumbersome and misses a lot of things like actual DWARF encoding. 3. Using elf-dump and examining the raw binary dumps. This makes tests nearly unmaintainable. The latter is also why IMHO our ELF emission in g...

...ticed 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 constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish patch, or could somebody else fix it, or can I just commit the change to svn? > Please submit a patch to llvm-commits, with a test case that exercises the fix. Eli

...what I was referring to in my last email: > "To be “correct”, tests should “require” (in the lit sense) features like > “function call”, etc. However this is a significant amount of work with > not that much added value. > This is what Takumi did to disable one test that check for “debug_frame” > which are not emitted on Windows.” > > I could try to survey all the failing tests and abstract the “features” > they are using, but this does not seem like a small enough task that I can > commit to an ETA now or have an estimate about when it’ll come on top of > my stack. &g...

...fo/DWARFContext.cpp Tue Feb 5 17:30:58 2013 >> @@ -31,6 +31,11 @@ void DWARFContext::dump(raw_ostream &OS, >> getCompileUnitAtIndex(i)->dump(OS); >> } >> >> + if (DumpType == DIDT_All || DumpType == DIDT_Frames) { >> + OS << "\n.debug_frame contents:\n"; >> + getDebugFrame()->dump(OS); >> + } >> + >> uint32_t offset = 0; >> if (DumpType == DIDT_All || DumpType == DIDT_Aranges) { >> OS << "\n.debug_aranges contents:\n"; >> @@ -152,6 +157,26 @@ const DWA...

...re standard DWARF2 sections that refer to labels and registers in the PTX. The PTX-to-SASS backend is responsible for generating the .debug_line section from the .file and .loc directives in the PTX file. This section maps source lines to SASS addresses. The PTX-to-SASS backend also generates the .debug_frame section. LLVM is able to emit debug info in DWARF. But ptxas compiler has some limitations, that make it hard to adapt LLVM for correct emission of the debug info in PTX files. Limitations/features of the PTX format/ptxas compiler. ================================== a) Supports DWARF-2 only. b)...

...not support label arithmetic in DWARF sections. Same. Please explain use case. d) Debug info must point to the sections, not to labels inside these sections. e) Sections itself must be enclosed into braces > “.section .debug_info {…}” Again, why is this a limitation? >>>> i) .debug_frame section is emitted by txas compiler. > DW_AT_frame_base must be set to dwarf::DW_FORM_data1 > dwarf::DW_OP_call_frame_cfa value. I doubt that's a problem. Why is this a problem? On Tue, Nov 7, 2017 at 1:33 AM, Alexey Bataev via llvm-dev <llvm-dev at lists.llvm.org<mailto:llv...

...registers in the >> PTX. >> >> The PTX-to-SASS backend is responsible for generating the .debug_line >> section from the .file and .loc directives in the PTX file. This >> section maps source lines to SASS addresses. The PTX-to-SASS backend >> also generates the .debug_frame section. > All this sounds like the standard division of responsibilities between > an LLVM code generator and the assembler. > >> LLVM is able to emit debug info in DWARF. But ptxas compiler has some >> limitations, that make it hard to adapt LLVM for correct emission of >&...

...m has with testing DWARF >> emission. We currently have several approaches, neither of which is >> great: >> >> 1. llvm-dwarfdump: the best approach when it works. But unfortunately >> lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections >> like debug_frame aren't supported. > > Could you point out what you mean? > In particular, what parts you think it does not support (since you say > it supports a small subset). > What do you want out of debug_frame, past simple parsing? > Anything else requires real evaluation. > As I sai...

...p; %ppc64run %t // RUN: %x86_64ecc -g -o %t %s && %x86_64run %t int comm; int main() { comm = 6; } This fails on all but the x86 processors. The typical failure looks like this: ... .type comm, at object # @comm .comm comm,4,4 .cfi_sections .debug_frame .bss .L.bss_end: ... .L.debug_abbrev_end: .section .debug_aranges,"", at progbits .long 36 # Length of ARange Set .short 2 # DWARF Arange version number .long .L.debug_info_begin0 # Offs...