On Fri, 8 Apr 2022 08:31:45 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> One way would be to check if we have either assembly source files, or >> anything in EXTRA_OBJ, and if so, do the relative linking. That would at >> least bring down collateral damage significantly, since the majority of libs >> have neither. >> >> It will still hurt the most important libs (like hotspot) but unless we >> can't find a way to get this working in some other way, it seems we'll have >> to accept that. >> >> @andrew-m-leonard Do you know if there is any bug on gcc tracking their >> inability to set debug prefix mapping for assembly files? > > Actually, I think that the GNU assembler supports debug prefix mapping. See > e.g. [this bug report](https://github.com/ocaml/ocaml/issues/10770), stating: > "With GNU tools, to enable debug prefix map on C source we pass > -fdebug-prefix-map to cc and --debug-prefix-map to as." > > @andrew-m-leonard Can you check if we can pass `--debug-prefix-map` to the > assembler if on the gcc toolchain, and thus get rid of the relative linking? > (And oh, speaking of that, the if statement here checks for target OS. It > should, most likely, have checked for toolchain.) @magicus thank you for looking at this, in hindsight I should have pinged you to review this as well. So a few thoughts, first one thing that crossed my mind which is the ifeq logic here should instead test ALLOW_ABSOLUTE_PATHS_IN_OUTPUT, exactly like the setting of -fdebug-prefix-map and -ffile-macro-prefix already do. In fact just changing to using that maybe sufficient? ie.only use relative paths here when ALLOW_ABSOLUTE_PATHS_IN_OUTPUT is false, ie. it is a "release" type build and not a developer/debug build, where CWD cmdlines are preferable. What's your thought on that? I did search google & bugzilla for any gcc bug, but didn't find anything. However, i've just found this issue: https://github.com/gcc-mirror/gcc/commit/d12153046816f955e74943af7089d30de6a00e19 which maybe related, although looks to do the opposite of what we want, although that maybe just because I don't understand it! However, it is the .file <path> dwarf value for the assembly stripped debuginfo that has the full object path that isn't getting stripped, and I think we do use -flto. This fix is in gcc 11.2, i'm testing using gcc 10.3. I'm going to do two things, recreate the problem again, double check the assembly file compile options, with gcc 10.3, then try again with gcc 11.2.. @magicus just saw your above post, interesting, i'll add I think gcc -v to my above testing, to see what gcc is passing through to the actual compile, apparently using verbose removes anything that gets removed for assembly, ie.anything that is not relavent ------------- PR: https://git.openjdk.java.net/jdk/pull/8124
