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

Sun May 28 08:12:00 PDT 2017

Ah, no. Debug build fails because of DWARF2 .file directives added by GCC.

On Sun, May 28, 2017 at 5:44 AM, Yusuke SUZUKI <utatane.tea at gmail.com>
wrote:

> 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/20170529/23759165/attachment-0001.html>