[webkit-gtk] [jsc-dev] Idea: DWARF in offlineasm output

Sat May 27 13:44:18 PDT 2017

Recently, I've just found that this works fine with my GCC environment
(Linux x64 GCC 5.4.0, AS 2.26.1).
I think we can enable it when compiling JSC with a newer GCC.

For WebKitGTK+ folks, can you reproduce it with your GCC versions?

Regards,
Yusuke Suzuki

On Wed, Jan 6, 2016 at 6:27 AM, Michael Saboff <msaboff at apple.com> wrote:

> Konstantin,
>
> Interesting results.
>
> [More inline]
>
> - Michael
>
> On Jan 5, 2016, at 12:55 PM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>
>
>
> 04.01.2016, 23:02, "Michael Saboff" <msaboff at apple.com>:
>
> Konstantin,
>
> Provided that gcc & gdb work with Dwarf2 .loc and .file directives and gcc
> can handle multiple .file directives in one file, it should work with that
> toolchain.  I just haven’t tested it.
>
> The single line change I added to the processor specific files, e.g.
> arm.rb, would need to be added to mips.rb and the other processor backend
> .rb files.  I also didn’t make those since I can’t test them either.
>
> If you could try add the single line change to mips.rb and test on gcc /
> gdb that would be great.
>
>
> I've tried your patch with gcc/gdb on x86_64 and MIPS (both Linux). Here
> are results:
>
> 1. GCC itself does not care about .file directives at all, ignoring
> contents of asm completely
>
> 2. After this, GNU as bails out because of 2 copies of .file 1 etc. To fix
> this problem, I've applied attached patch to your code, adding offset to
> file numbers. This offset unfortunately depends on how many .file
> directives were emitted by GCC itself, and it cannot be set to large number
> like 1000 because as does not accept holes.
>
>
> If you look at the assembler output of *gcc -s … LowLevelInterpreter.cpp*,
> does it show a *.file* directive for *LowLevelInterpreter.cpp* itself?
> Likely we’ll need *$fileIndexOffset* initialized differently depending on
> the platform / compiler.
>
> 3. After this change, compilation succeeds on both x86_64 and MIPS in
> debug and release. However, source debug works fine only in release (on
> both MIPS and x86_64), it looks like in debug mode gdb is confused (setting
> breakpoints sort of works, but gdb fails to link currently executed
> instruction with source)
>
>
> What I tested with lldb is stack traces, single stepping and breakpoints,
> although breakpoints weren’t the most reliable.  Does single stepping and
> stack traces work for debug builds?  Does a release build provide
> reasonable behavior for all aspects of debugging LLInt .asm files?
>
> I can think of the next possible workarounds:
>
> 1. Always build LowLevelInterpreter.cpp in Release mode, because all
> interesting debug info is in asm.
> 2. Make offlineasm produce separate .S (preprocessed asm) source file
> which won't be touched by C++ compiler at all.
>
>
> I don’t like option 1.  Hard coding *LowLevelInterpreter.cpp* to be
> always build release could get messy and is not what we want when compiling
> for the C-Loop or probably for Windows.  Option 2 is what happens with
> Windows builds.  That is a possible, although still a problematic option.
> The offline assembler would need to be taught about symbol exporting and
> creating the sections, etc for all platforms.  Much of this could be done
> with canned header and footer files that are output as part of the offline
> assembler processing.  There would likely need to be different files for
> different platforms.  That would create a maintenance overhead when
> introducing a new compiler or major compiler upgrade.  That is why the
> current method of passing the inline assembly through the C++ compiler is
> attractive.
>
> Let’s try to find a good solution for the duplicate .file problem before
> we go down an option 2 path.
>
>
>
> - Michael
>
> On Jan 4, 2016, at 11:47 AM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>
> 04.01.2016, 22:39, "Michael Saboff" <msaboff at apple.com>:
>
> Konstantin,
>
> Actually, that change hasn’t been landed.  I have been waiting for a fix
> in the clang toolchain.  I have provided that fix to the clang team, but it
> hasn’t landed yet.
>
> I posted my DWARF2 changes to the bug: <https://bugs.webkit.org/show_
> bug.cgi?id=152703> - “offlineasm: Emit Dwarf2 file and location
> directives to allow for debugging .asm files”.
>
> I’ll work with the clang team to get that change done.
>
> If you are willing, it would be good to get gcc/gdb working with the
> change as well.  I only did changes for the compiler (clang) and CPUs (X86,
> ARM & ARM64) that I could test.
>
>
> Michael,
>
> Problem is that I'm using gcc (and my target is MIPS). Does your change
> work with GCC, or this is clang-only feature?
>
> Though I guess it should be feasible to build one assembly file with clang
> using its MIPS backend, and use gcc for the rest of build.
>
> - Michael
>
> On Jan 4, 2016, at 10:47 AM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>
> 04.01.2016, 21:41, "Geoffrey Garen" <ggaren at apple.com>:
>
> Michael Saboff recently added file and line number annotations to
> offlineasm.
>
> What other kinds of information would you add using DWARF? How would you
> update the DWARF information when the .asm file changed?
>
>
> I thought it would be useful to have files and line numbers as DWARF
> instead of comments so it would be easier to single-step with gdb.
>
> Also, macros could be annotated as inline functions.
>
> However, for now I've fixed crash that I was struggling with.
>
> Geoff
>
>  On Jan 3, 2016, at 12:48 PM, Konstantin Tokarev <annulen at yandex.ru>
> wrote:
>
>  Hi JSC developers,
>
>  Haven't you ever considered adding DWARF information into assembly
> produced by offlineasm? I'm trying to fix MIPS backend right now, and I
> thought it may be useful to debug crashes in LLINT.
>
>  --
>  Regards,
>  Konstantin
>  _______________________________________________
>  jsc-dev mailing list
>  jsc-dev at lists.webkit.org
>  https://lists.webkit.org/mailman/listinfo/jsc-dev
>
>
> --
> Regards,
> Konstantin
> _______________________________________________
> jsc-dev mailing list
> jsc-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/jsc-dev
>
>
> --
> Regards,
> Konstantin
>
>
>
> --
> Regards,
> Konstantin
> <parser.patch>
>
>
>
> _______________________________________________
> jsc-dev mailing list
> jsc-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/jsc-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20170528/21a53023/attachment-0001.html>