[Webkit-unassigned] [Bug 207119] Enable offlineasm debug annotations for GCC

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 26 06:24:55 PDT 2020


https://bugs.webkit.org/show_bug.cgi?id=207119

--- Comment #24 from Angelos Oikonomopoulos <angelos at igalia.com> ---
(In reply to Konstantin Tokarev from comment #21)
> (In reply to Angelos Oikonomopoulos from comment #18)
> > - unconditionally emit marker symbols around the top-level inline asm
> > statement in LowLevelInterpreter.cpp, as this has nothing to do with the
> > build toolchain and everything to do with the ability to debug using gdb.
> > However, clang doesn't currently support __no_reorder__ so this is
> > effectively a no-op.
> 
> Do I understand correctly that GDB just needs to have .cfi_startproc and
> .cfi_endproc here to start using following .file and .loc directives?

As far as I understand, that's not the issue. The issue is that no DW_AT_{low,high}_pc (or even DW_AT_ranges) is generated for LowLevelInterpreter.cpp. Then, dwarf2_record_block_ranges won't record an address range for it (https://github.com/bminor/binutils-gdb/blob/master/gdb/dwarf2/read.c#L14021) and find_pc_sect_compunit_symtab will not be able to resolve any PC to this CU (https://github.com/bminor/binutils-gdb/blob/19a2740f7f2ea0f65745a3c00cf8a64647378aa3/gdb/symtab.c#L2911).

Not sure why the dwarf attributes are not generated. Testing on a simpler testcase, I can confirm that
- .cfi_{start,end}proc don't make a difference
- .type foo, at function doesn't help
- .func/.endfunc don't make a difference either
- turning off debug fission also doesn't help

I've timed out looking into GDB internals.

> If so, we might want to emit minimal assembly stub here via asm volatile
> instead of inserting unused function body. I think it may express intention
> more clearly even for GCC case, and should work with Clang as well.

Agreed, but this seems orthogonal to this issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200326/8a8963a7/attachment-0001.htm>


More information about the webkit-unassigned mailing list