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

[Andrew Leonard]

On Fri, 8 Apr 2022 13:11:32 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>>> While we're at it, let me repeat my question from the alias:
>>> 
>>> I was wondering why were the changes in `make/autoconf/flags-cflags.m4` made under:
>>> 
>>> ```
>>> if test "x$TOOLCHAIN_TYPE" = xgcc; then ...
>>> ```
>>> 
>>> but not also propagated to the clang branch down below
>>> 
>>> ```
>>> elif test "x$TOOLCHAIN_TYPE" = xclang; then ...
>>> ```
>>> 
>>> ?
>>> 
>>> It seems like the same would be required to make builds by `clang` reproducible and `clang` does support the same option, spelling and all.
>> 
>> That is simply because I have not test full reproducibility on MacOS, the intention of this PR was for Linux platforms.
>> Although MacOS is my next port of investigation for reproducibility as a whole..
>
>> That is simply because I have not test full reproducibility on MacOS, the intention of this PR was for Linux platforms.
>> Although MacOS is my next port of investigation for reproducibility as a whole..
> 
> @andrew-m-leonard Thank you for the clarification! 
> 
> Again, FWIW doing same on MacOS achieved the same reproducible result as on Linux. The only thing I won't vouch for is how necessary it is on MacOS; maybe some options can be omitted for `clang`, for example. I simply did the exact same thing without much investigation as to why it worked.

@mkartashev Maxim, just tried your solution on one of the assembly files, and it does resolve the absolute path for it. I did a readelf, and I can see the entry that was absolute before is now what I specified in the .S assembly:

 31712: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS atomic_linux_aarch64.S
 31714: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS /home/andrew3/jdk/build/l
 31725: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS /home/andrew3/jdk/build/l

I can't seem to find any online assembly documentation(?) that states that a .file symbol pointing to the absolute object file name is produced, but it obviously does! In fact maybe it's to do with how the linker generates them, as using relative path for the link changed it...?

@magicus I will create a new PR, with .file <...S> directives added to the linux platform assembly files, and undo the relative path linking. Does that seem reasonable?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8124