Ah, no. Debug build fails because of DWARF2 .file directives added by GCC. On Sun, May 28, 2017 at 5:44 AM, Yusuke SUZUKI <[email protected]> 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 <[email protected]> wrote: > >> Konstantin, >> >> Interesting results. >> >> [More inline] >> >> - Michael >> >> On Jan 5, 2016, at 12:55 PM, Konstantin Tokarev <[email protected]> >> wrote: >> >> >> >> 04.01.2016, 23:02, "Michael Saboff" <[email protected]>: >> >> 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 <[email protected]> >> wrote: >> >> 04.01.2016, 22:39, "Michael Saboff" <[email protected]>: >> >> 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 <[email protected]> >> wrote: >> >> 04.01.2016, 21:41, "Geoffrey Garen" <[email protected]>: >> >> 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 <[email protected]> >> 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 >> [email protected] >> https://lists.webkit.org/mailman/listinfo/jsc-dev >> >> >> -- >> Regards, >> Konstantin >> _______________________________________________ >> jsc-dev mailing list >> [email protected] >> https://lists.webkit.org/mailman/listinfo/jsc-dev >> >> >> -- >> Regards, >> Konstantin >> >> >> >> -- >> Regards, >> Konstantin >> <parser.patch> >> >> >> >> _______________________________________________ >> jsc-dev mailing list >> [email protected] >> https://lists.webkit.org/mailman/listinfo/jsc-dev >> >> >
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
