On Fri, 8 Apr 2022 14:48:41 GMT, Andrew Leonard <aleon...@openjdk.org> wrote:
>> I am not sure why without the explicit .file directive that the FILE symbol >> in the ELF info contains an entry pointing to the .o object file, here's >> what it was before: >> >> 31712: 0000000000000000 0 FILE LOCAL DEFAULT ABS >> /home/andrew2/jdk/build/linux-aarch64-server-release/hotspot/variant-server/libjvm/objs/atomic_linux_aarch64.o >> >> It's as if the lack of the .file has caused some tooling (linker?) to create >> this entry using the .o file path. > >> @andrew-m-leonard >> >> > So I am thinking adding a .file directive to the .S file specifying the >> > "full source path" should do the trick thanks to -debug-prefix-map, I will >> > do a test.. >> >> But then you'll end up with that absolute path name embedded into `STT_FILE` >> in the object file. It's best to use the relative path name _and_ employ >> path mapping. > > @mkartashev of course yes it would make the .o non-reproducible, so yes makes > sense "relative path name _and_ employ path mapping." @andrew-m-leonard Just to clarify, if you create a new PR, where you revert the introduced relative path linking, add `.file THIS_FILE` to all assembly (*.S) files, and pass `-DTHIS_FILE=$relative_file_name` and `-fdebug-prefix-map` to gcc, then I'm perfectly happy! ------------- PR: https://git.openjdk.java.net/jdk/pull/8124
