search for: cfi_

Hi, Compiling a simple function with the 3.0 SVN branch llc produces .s output containing cfi_startproc, cfi_endproc, cfi_def_cfa_offset that gcc refuses to compile (OS X 10.7 on X86-64) with the following error: test.s:6:Unknown pseudo-op: .cfi_startproc test.s:10:Unknown pseudo-op: .cfi_def_cfa_offset test.s:10:Rest of line ignored. 1st junk character valued 51 (3). test.s:38:Unknown pseu...

...on. 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 general isn't well tested. elf-dump is just too rudimentary and relies on...

...ask because I wrote a DWARF reader that google uses internally, and then was open sourced and contributed to google breakpad. (see http://code.google.com/p/google-breakpad/source/browse/trunk/src/common/dwarf/, in particular dwarf2reader.cc). > 2. Relying of assembly directive emissions (i.e. .cfi_*), which is > cumbersome and misses a lot of things like actual DWARF encoding. Err, .cfi_ and used because the encoding is tricky to get right, and assemblers are better at optimizing it. However, i'll point out that breakpad also has a CFI assembler (http://code.google.com/p/google-breakp...

On 6 July 2017 at 11:02, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Grang, Mandeep Singh wrote: >> I would like to hear the community's thoughts on these proposals. >From the perspective of the recent focused effort on reproducible builds, I think this is excellent. >> We ideally want to compare rel vs >> rel+asserts vs debug with Linux vs

...yway. See test/MC/ELF/cfi-register.s for a test I consider unmaintainable since it just matches an elf-dump and requires manual decoding of the data for every change and addition. When tests are too hard to write, fewer tests get written. >> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >> cumbersome and misses a lot of things like actual DWARF encoding. > > I'm not sure what you mean by "actual DWARF encoding" here. > (disclaimer: I've only recently started dabbling with debug info, so I > may be missing obvious things) I mean that...

...fixed by now (at one point > they were counted in inlining costs, which meant that -g affected > inlining decisions!), but we see it now and again. > > There can also be minor instruction-ordering effects because -g wants > to emit unwind info, which appears in the form of assembler .cfi_* > directives, and those appear to be instruction-ordering barriers. > That's the one that pops to mind as something we haven't tried to fix. > > There might be others, I haven't looked at that stuff lately. > --paulr > > ____________________________________________...

>>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >>> cumbersome and misses a lot of things like actual DWARF encoding. >> >> I'm not sure what you mean by "actual DWARF encoding" here. >> (disclaimer: I've only recently started dabbling with debug info, so I >> may be missing obvious...

...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 general isn't well > tested. elf-dump is just t...

...DWARF reader that google uses internally, and > then was open sourced and contributed to google breakpad. > (see http://code.google.com/p/google-breakpad/source/browse/trunk/src/common/dwarf/, > in particular dwarf2reader.cc). > >> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >> cumbersome and misses a lot of things like actual DWARF encoding. > > Err, .cfi_ and used because the encoding is tricky to get right, and > assemblers are better at optimizing it. > However, i'll point out that breakpad also has a CFI assembler > (http://cod...

On Tue, Jan 22, 2013 at 3:23 PM, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: >>>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >>>> cumbersome and misses a lot of things like actual DWARF encoding. >>> >>> I'm not sure what you mean by "actual DWARF encoding" here. >>> (disclaimer: I've only recently started dabbling with debug info, so I >>> may...

Hi, We would like to upstream exception handling support for Windows on ARM64. Microsoft-published specifications can be found here: a) https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling b) https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions We propose the following approach: 1) Upstream miscellaneous clang and llvm patches that are

...to add new features to llvm-dwarfdump before there's a use-case. It does sometimes mean bug fixes appear to be costly because they include adding the missing test infrastructure support, but that's essentially where the cost is anyway. > 2. Relying of assembly directive emissions (i.e. .cfi_*), which is > cumbersome and misses a lot of things like actual DWARF encoding. I'm not sure what you mean by "actual DWARF encoding" here. (disclaimer: I've only recently started dabbling with debug info, so I may be missing obvious things) > 3. Using elf-dump and examini...

...2 PM, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: > David Blaikie [dblaikie at gmail.com] wrote: >> On Tue, Jan 22, 2013 at 3:23 PM, Robinson, Paul >> <Paul.Robinson at am.sony.com> wrote: >>>>>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >>>>>> cumbersome and misses a lot of things like actual DWARF encoding. >>>>> >>>>> I'm not sure what you mean by "actual DWARF encoding" here. >>>>> (disclaimer: I've only recently started dabbling with d...

David Blaikie [dblaikie at gmail.com] wrote: > On Tue, Jan 22, 2013 at 3:23 PM, Robinson, Paul > <Paul.Robinson at am.sony.com> wrote: >>>>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >>>>> cumbersome and misses a lot of things like actual DWARF encoding. >>>> >>>> I'm not sure what you mean by "actual DWARF encoding" here. >>>> (disclaimer: I've only recently started dabbling with debug info, so I...

In your sequences in asm/paravirt.h, you explicitly save the caller-save regs: static inline void raw_local_irq_restore(unsigned long f) { __asm__ __volatile__(paravirt_alt("pushl %%ecx; pushl %%edx\n\t" "pushl %1; call *%0\n\t" "popl %1; popl %%edx; popl %%ecx", PARAVIRT_RESTORE_FLAGS) : : "m" (paravirt_ops.restore_fl),

Hi All, I am trying to emit dwarf debug information for my target. By using objdump or llvm-objdump with `--dwarf=frames`, I can only see CIE (Common Information Entry) but not FDE (Frame Description Entry). Right now, my target LLVM backend only emit assembly, and let binutils do the rest. I don't know where the problem is, is there something wrong in my target LLVM backend or in the

>> 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 general isn't well >> te...