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
