RFR: 8284437: Building from different users/workspace is not always deterministic [v2]

[Magnus Ihse Bursie]

On Fri, 8 Apr 2022 14:48:41 GMT, Andrew Leonard <aleonard at 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