[jsc-dev] Idea: DWARF in offlineasm output

Tue Jan 5 13:27:37 PST 2016

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 <mailto: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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/jsc-dev/attachments/20160105/a4a8e942/attachment-0001.html>