RFR: 8284661: Reproducible assembly builds without relative linking
This PR removes the need for relative object file linking introduced by JDK-8284437 for linux libraries, by specifying .file directives in the linux .S source files. The source files specify a .file ASSEMBLY_SRC_FILE where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. Signed-off-by: Andrew Leonard - Commit messages: - 8284661: Reproducible assembly builds without relative linking Changes: https://git.openjdk.java.net/jdk/pull/8177/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284661 Stats: 32 lines in 7 files changed: 15 ins; 13 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8177/head:pull/8177 PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 09:43:37 GMT, Andrew Leonard wrote: > This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard dwarf debuginfo output for the assembly entries now looks good: < 0><0x000b> DW_TAG_compile_unit DW_AT_stmt_list 0x0022146d DW_AT_low_pc0x004707c0 DW_AT_high_pc 0x00470a40 DW_AT_name src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S DW_AT_comp_dir make/hotspot DW_AT_producer GNU AS 2.27 DW_AT_language DW_LANG_Mips_Assembler - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 09:43:37 GMT, Andrew Leonard wrote: > This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Maybe some short explanation should be added as comment in the src files? If this makes the debuginfo files free from absolute paths on Linux, could you also adjust `open/test/jdk/build/AbsPathsInImage.java` to include those files on Linux? Would be good to be able to catch any regression to this behavior in the future. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 09:43:37 GMT, Andrew Leonard wrote: > This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Non-determinism in .debuginfo straight away makes .so libraries non-deterministic due to the embedded debuginfo CRC value. @erikj79 i'll try removing .debuginfo from the exceptions and try it... - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 12:55:16 GMT, Erik Joelsson wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Maybe some short explanation should be added as comment in the src files? > > If this makes the debuginfo files free from absolute paths on Linux, could > you also adjust `open/test/jdk/build/AbsPathsInImage.java` to include those > files on Linux? Would be good to be able to catch any regression to this > behavior in the future. thanks @erikj79 Not familiar with AbsPathsInImage, could you give some background please? wondering why it's not found these paths before, maybe it's not running on debugimages? What tier does it get run in? @erikj79 this would be why: https://github.com/openjdk/jdk/blob/d442328bc2f2f4bc35dd054487a78552e3d9a759/test/jdk/build/AbsPathsInImage.java#L167 - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 14:05:54 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Non-determinism in .debuginfo straight away makes .so libraries > non-deterministic due to the embedded debuginfo CRC value. > @erikj79 i'll try removing .debuginfo from the exceptions and try it... @andrew-m-leonard This change leaves the pathmap options intact, right? Because `clang` leaves absolute path names in the debug info regardless of what's in `.file`. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 14:05:54 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Non-determinism in .debuginfo straight away makes .so libraries > non-deterministic due to the embedded debuginfo CRC value. > @erikj79 i'll try removing .debuginfo from the exceptions and try it... > @andrew-m-leonard This change leaves the pathmap options intact, right? > Because `clang` leaves absolute path names in the debug info regardless of > what's in `.file`. @mkartashev yes, that was in the already merged PR : https://github.com/openjdk/jdk/commit/4451257b1432e4180a16757aafca6141b8063772 So clang / MacOS needs deeper investigation, the AbsPathInImage test currently also excludes .dSYM folder. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 14:50:37 GMT, Andrew Leonard wrote: >> Non-determinism in .debuginfo straight away makes .so libraries >> non-deterministic due to the embedded debuginfo CRC value. >> @erikj79 i'll try removing .debuginfo from the exceptions and try it... > >> @andrew-m-leonard This change leaves the pathmap options intact, right? >> Because `clang` leaves absolute path names in the debug info regardless of >> what's in `.file`. > > @mkartashev yes, that was in the already merged PR : > https://github.com/openjdk/jdk/commit/4451257b1432e4180a16757aafca6141b8063772 > > So clang / MacOS needs deeper investigation, the AbsPathInImage test > currently also excludes .dSYM folder. Hi @andrew-m-leonard, I am currently working on moving SafeFetch to static assembly: https://github.com/openjdk/jdk/pull/7865 Would your change affect that, especially the ability to export inner-function labels as jump-back-points? Also, riscv, ppcle and s390 are missing, why not do it on all platforms? Thanks! - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 14:50:37 GMT, Andrew Leonard wrote: >> Non-determinism in .debuginfo straight away makes .so libraries >> non-deterministic due to the embedded debuginfo CRC value. >> @erikj79 i'll try removing .debuginfo from the exceptions and try it... > >> @andrew-m-leonard This change leaves the pathmap options intact, right? >> Because `clang` leaves absolute path names in the debug info regardless of >> what's in `.file`. > > @mkartashev yes, that was in the already merged PR : > https://github.com/openjdk/jdk/commit/4451257b1432e4180a16757aafca6141b8063772 > > So clang / MacOS needs deeper investigation, the AbsPathInImage test > currently also excludes .dSYM folder. > Hi @andrew-m-leonard, I am currently working on moving SafeFetch to static > assembly: > > #7865 > > Would your change affect that, especially the ability to export > inner-function labels as jump-back-points? hi @tstuefe Thomas, this is only requiring .file directives in linux .S files, which will mean your PR will require the line: .file ASSEMBLY_SRC_FILE assuming they don't already have a .file... but I don't think it should affect anything else you're doing. This is for reproducible builds, and every platform has it's own issues with respect to this. In this particular Linux case, the linker embeds it's own .file symbol if one isn't present using the .o object path name. Other platforms will have there own quirks we need to fix > > Also, riscv, ppcle and s390 are missing, why not do it on all platforms? Which .S files am I missing for these flavors of Linux? - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 12:55:16 GMT, Erik Joelsson wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Maybe some short explanation should be added as comment in the src files? > > If this makes the debuginfo files free from absolute paths on Linux, could > you also adjust `open/test/jdk/build/AbsPathsInImage.java` to include those > files on Linux? Would be good to be able to catch any regression to this > behavior in the future. > thanks @erikj79 Not familiar with AbsPathsInImage, could you give some > background please? wondering why it's not found these paths before, maybe > it's not running on debugimages? What tier does it get run in? I wrote this test when introducing the --disable-absolute-paths-in-output functionality, so we could verify that no absolute paths made it into any part of the output that we eventually ship to customers. I excluded all kinds of debuginfo files because I didn't know if they could be made free of absolute paths, and it was out of scope for what I was doing at the time. I believe we run this test as part of our tier2 internally at Oracle. I think generally it's an optional test as it relies on a specific build configuration that all builders of OpenJDK may not want to use. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 16:58:38 GMT, Erik Joelsson wrote: > > thanks @erikj79 Not familiar with AbsPathsInImage, could you give some > > background please? wondering why it's not found these paths before, maybe > > it's not running on debugimages? What tier does it get run in? > > I wrote this test when introducing the --disable-absolute-paths-in-output > functionality, so we could verify that no absolute paths made it into any > part of the output that we eventually ship to customers. I excluded all kinds > of debuginfo files because I didn't know if they could be made free of > absolute paths, and it was out of scope for what I was doing at the time. > > I believe we run this test as part of our tier2 internally at Oracle. I think > generally it's an optional test as it relies on a specific build > configuration that all builders of OpenJDK may not want to use. Thanks for the background, we also run it as an "extended" test at Adoptium i've discovered. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Mon, 11 Apr 2022 17:27:35 GMT, Andrew Leonard wrote: > I excluded all kinds of debuginfo files because I didn't know if they could > be made free of absolute paths, and it was out of scope for what I was doing > at the time. GCC, I believe, uses whatever pathname you give to the compiler in the debuginfo. If you give GCC relative pathnames, that's what it emits. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Tue, 12 Apr 2022 08:39:54 GMT, Andrew Haley wrote: > > I excluded all kinds of debuginfo files because I didn't know if they could > > be made free of absolute paths, and it was out of scope for what I was > > doing at the time. > > GCC, I believe, uses whatever pathname you give to the compiler in the > debuginfo. If you give GCC relative pathnames, that's what it emits. @theRealAph The current strategy is to retain full paths in cmdlines, so that they can be copy & pasted from logs and just invoked, if relative paths are used then you need to be in the right place. Hence instead to achieve relative paths in the debuginfo, we need to use --debug-prefix-map option. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v2]
> This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision: 8284661: Reproducible assembly builds without relative linking Signed-off-by: Andrew Leonard - Changes: - all: https://git.openjdk.java.net/jdk/pull/8177/files - new: https://git.openjdk.java.net/jdk/pull/8177/files/c73579e2..d32473ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=00-01 Stats: 14 lines in 7 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8177/head:pull/8177 PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
> This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision: 8284661: Reproducible assembly builds without relative linking Signed-off-by: Andrew Leonard - Changes: - all: https://git.openjdk.java.net/jdk/pull/8177/files - new: https://git.openjdk.java.net/jdk/pull/8177/files/d32473ba..748485d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=01-02 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8177/head:pull/8177 PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with one additional > commit since the last revision: > > 8284661: Reproducible assembly builds without relative linking > > Signed-off-by: Andrew Leonard @magicus @mkartashev For your reviews please. I'm also currently running a full platform build at Adoptium, so as to ensure validation on all Linux flavors (https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk19-pipeline/88/parameters/), and plan to run AbsPathsInImage against them all. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote:
>> This PR removes the need for relative object file linking introduced by
>> JDK-8284437 for linux libraries, by specifying
>> .file directives in the linux .S source files. The
>> source files specify a .file ASSEMBLY_SRC_FILE
>> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk.
>>
>> Signed-off-by: Andrew Leonard
>
> Andrew Leonard has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8284661: Reproducible assembly builds without relative linking
>
> Signed-off-by: Andrew Leonard
test/jdk/build/AbsPathsInImage.java line 167:
> 165: if (Files.isSymbolicLink(file)) {
> 166: return super.visitFile(file, attrs);
> 167: } else if (fileName.endsWith(".pdb")) {
The .debuginfo suffix has at least historically been used on more OSes than
just Linux. I think we should only include .debuginfo files in this test if the
OS is also Linux.
-
PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 16:17:08 GMT, Andrew Leonard wrote: >> Andrew Leonard has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8284661: Reproducible assembly builds without relative linking >> >> Signed-off-by: Andrew Leonard > > @magicus @mkartashev For your reviews please. > I'm also currently running a full platform build at Adoptium, so as to ensure > validation on all Linux flavors > (https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk19-pipeline/88/parameters/), > and plan to run AbsPathsInImage against them all. > > Hi @andrew-m-leonard, I am currently working on moving SafeFetch to static > > assembly: > > #7865 > > Would your change affect that, especially the ability to export > > inner-function labels as jump-back-points? > > hi @tstuefe Thomas, this is only requiring .file directives in linux .S > files, which will mean your PR will require the line: > > ``` > .file ASSEMBLY_SRC_FILE > ``` > > assuming they don't already have a .file... but I don't think it should > affect anything else you're doing. > Thanks, I'll try it out. > > Also, riscv, ppcle and s390 are missing, why not do it on all platforms? > > Which .S files am I missing for these flavors of Linux? Oh right, my patch introduces the first S files on those platforms, there are none today. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 16:53:41 GMT, Erik Joelsson wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8284661: Reproducible assembly builds without relative linking
>>
>> Signed-off-by: Andrew Leonard
>
> test/jdk/build/AbsPathsInImage.java line 167:
>
>> 165: if (Files.isSymbolicLink(file)) {
>> 166: return super.visitFile(file, attrs);
>> 167: } else if (fileName.endsWith(".pdb")) {
>
> The .debuginfo suffix has at least historically been used on more OSes than
> just Linux. I think we should only include .debuginfo files in this test if
> the OS is also Linux.
@erikj79 As far as I can see only AIX is the exception of not being Linux and
using .debuginfo suffix, are there others?
I am currently testing AIX, so I will see if it passes, as you say, I would
have my doubts it will!
-
PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 17:26:12 GMT, Andrew Leonard wrote:
>> test/jdk/build/AbsPathsInImage.java line 167:
>>
>>> 165: if (Files.isSymbolicLink(file)) {
>>> 166: return super.visitFile(file, attrs);
>>> 167: } else if (fileName.endsWith(".pdb")) {
>>
>> The .debuginfo suffix has at least historically been used on more OSes than
>> just Linux. I think we should only include .debuginfo files in this test if
>> the OS is also Linux.
>
> @erikj79 As far as I can see only AIX is the exception of not being Linux and
> using .debuginfo suffix, are there others?
> I am currently testing AIX, so I will see if it passes, as you say, I would
> have my doubts it will!
Solaris used that extension as well. It's no longer supported in mainline, but
if you backport this, which I assume you will want to, then someone may hit it.
-
PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 17:40:58 GMT, Erik Joelsson wrote:
>> @erikj79 As far as I can see only AIX is the exception of not being Linux
>> and using .debuginfo suffix, are there others?
>> I am currently testing AIX, so I will see if it passes, as you say, I would
>> have my doubts it will!
>
> Solaris used that extension as well. It's no longer supported in mainline,
> but if you backport this, which I assume you will want to, then someone may
> hit it.
ah right yes Solaris
I'll add a suitable System.getProperty("os.name").contains("Linux")
-
PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with one additional > commit since the last revision: > > 8284661: Reproducible assembly builds without relative linking > > Signed-off-by: Andrew Leonard Looks like there is way too few .S files in this patch. $ find . -name "*.S" ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan2_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tanh_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tan_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cbrt_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log10_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cosh_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log1p_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_exp_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_hypot_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_expm1_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sinh_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_acos_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_asin_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_exp_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_expm1_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cos_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_asin_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_hypot_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sinh_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sin_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_acos_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log1p_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log10_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tanh_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_pow_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cosh_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cbrt_linux_x86.S ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan2_linux_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tanh_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log10_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_exp_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log10_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log1p_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_pow_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cosh_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cosh_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log1p_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tan_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_pow_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_hypot_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sin_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_hypot_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_asin_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_asin_windows_x86.S ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_expm1_windows_x86.S ./jd
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 21:03:22 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8284661: Reproducible assembly builds without relative linking >> >> Signed-off-by: Andrew Leonard > > Looks like there is way too few .S files in this patch. > > > $ find . -name "*.S" > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan2_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tanh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tan_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cbrt_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log10_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cosh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log1p_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_exp_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_hypot_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_expm1_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sinh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_acos_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_asin_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_exp_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_expm1_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cos_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_asin_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_hypot_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sinh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sin_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_acos_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log1p_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log10_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tanh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_pow_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cosh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cbrt_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan2_linux_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tanh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log10_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_exp_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log10_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log1p_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_pow_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cosh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cosh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log1p_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tan_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_pow_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_hypot_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sin_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_hypot_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_asin_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_asin_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_expm1_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cos_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sinh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with one additional > commit since the last revision: > > 8284661: Reproducible assembly builds without relative linking > > Signed-off-by: Andrew Leonard > Looks like there is way too few .S files in this patch. > > ``` > $ find . -name "*.S" > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan2_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tanh_linux_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log10_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_exp_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan2_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_expm1_windows_x86.S > ./hotspot/os_cpu/linux_arm/linux_arm_32.S > ./hotspot/os_cpu/linux_x86/linux_x86_32.S > ./hotspot/os_cpu/linux_x86/linux_x86_64.S > ./hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S > ./hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S > ./hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S > ./hotspot/os_cpu/bsd_x86/bsd_x86_32.S > ./hotspot/os_cpu/bsd_x86/bsd_x86_64.S > ./hotspot/os_cpu/bsd_aarch64/copy_bsd_aarch64.S > ``` > > (You can leave out the windows files) @magicus all those incubator ones already have there own ".file " in them, so is already relative as it were.. I think these are pre-canned Intel/RedHat assembler maths functions taken as-is, so I thought best to leave the existing .file as-is. I did all the linux ones, and left Windows and Mac bsd ones. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 21:03:22 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8284661: Reproducible assembly builds without relative linking >> >> Signed-off-by: Andrew Leonard > > Looks like there is way too few .S files in this patch. > > > $ find . -name "*.S" > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan2_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tanh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tan_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cbrt_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log10_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cosh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log1p_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_exp_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_hypot_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_expm1_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sinh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_acos_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_asin_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_exp_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_expm1_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cos_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_asin_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_hypot_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sinh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sin_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_acos_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log1p_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log10_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tanh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_s_pow_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cosh_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cbrt_linux_x86.S > ./jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan2_linux_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tanh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log10_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_exp_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log10_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log1p_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_pow_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cosh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cosh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log1p_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tan_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_pow_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_hypot_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sin_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_hypot_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_asin_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_asin_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_expm1_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cos_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sinh_windows_x86.S > ./jdk.incubator.vector/windows/native/libjsvml/jsvml
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with one additional > commit since the last revision: > > 8284661: Reproducible assembly builds without relative linking > > Signed-off-by: Andrew Leonard I agree with David. We need to update all files to use the same method for `.file`. I prefer to do it as part of this PR, so we can verify that all assembly files have correct data. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with one additional > commit since the last revision: > > 8284661: Reproducible assembly builds without relative linking > > Signed-off-by: Andrew Leonard Actually, a better option might be to let GCC append the `.file` automatically to all assembly files. I think this can be done by creating a file like `make/data/autoheaders/assemblyprefix.h` with: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file path // in NativeCompilation.gmk, this ensures reproducible .debuginfo .file ASSEMBLY_SRC_FILE and then add `-include $TOPDIR/make/data/autoheaders/assemblyprefix.h` to the gcc assembly command line. I have not verified this so it needs to be checked. I also think we should remove the `.file` keyword from the incubator files. (Nothing good can come out of having two `.file` attributes.) - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Tue, 12 Apr 2022 10:27:30 GMT, Magnus Ihse Bursie wrote: > Actually, a better option might be to let GCC append the `.file` > automatically to all assembly files. I think this can be done by creating a > file like `make/data/autoheaders/assemblyprefix.h` with: > > ``` > // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file path > // in NativeCompilation.gmk, this ensures reproducible .debuginfo > .file ASSEMBLY_SRC_FILE > ``` > > and then add `-include $TOPDIR/make/data/autoheaders/assemblyprefix.h` to the > gcc assembly command line. > > I have not verified this so it needs to be checked. > > I also think we should remove the `.file` keyword from the incubator files. > (Nothing good can come out of having two `.file` attributes.) @magicus this sounds good, i'll give it a try - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
> This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision: 8284661: Reproducible assembly builds without relative linking Signed-off-by: Andrew Leonard - Changes: - all: https://git.openjdk.java.net/jdk/pull/8177/files - new: https://git.openjdk.java.net/jdk/pull/8177/files/748485d7..f9a53868 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=02-03 Stats: 71 lines in 8 files changed: 41 ins; 27 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8177/head:pull/8177 PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
On Wed, 13 Apr 2022 11:30:14 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with one additional > commit since the last revision: > > 8284661: Reproducible assembly builds without relative linking > > Signed-off-by: Andrew Leonard The latest version looks much better! Fix the test to check for linux, and the indentation in the new header file, and I'd say you're good to go! make/data/autoheaders/assemblyprefix.h line 24: > 22: # > 23: > 24: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file > path While not critical, the indentation here looks surprising and odd. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
On Wed, 13 Apr 2022 11:36:41 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8284661: Reproducible assembly builds without relative linking >> >> Signed-off-by: Andrew Leonard > > make/data/autoheaders/assemblyprefix.h line 24: > >> 22: # >> 23: >> 24: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file >> path > > While not critical, the indentation here looks surprising and odd. I was keeping it inline with what's in the other .S files - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
On Wed, 13 Apr 2022 11:41:14 GMT, Andrew Leonard wrote: >> make/data/autoheaders/assemblyprefix.h line 24: >> >>> 22: # >>> 23: >>> 24: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file >>> path >> >> While not critical, the indentation here looks surprising and odd. > > I was keeping it inline with what's in the other .S files i'll change - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v5]
> This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision: - 8284661: Reproducible assembly builds without relative linking Signed-off-by: Andrew Leonard - 8284661: Reproducible assembly builds without relative linking Signed-off-by: Andrew Leonard - Changes: - all: https://git.openjdk.java.net/jdk/pull/8177/files - new: https://git.openjdk.java.net/jdk/pull/8177/files/f9a53868..4245e704 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=03-04 Stats: 79 lines in 39 files changed: 1 ins; 36 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/8177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8177/head:pull/8177 PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
On Wed, 13 Apr 2022 11:37:36 GMT, Magnus Ihse Bursie wrote: > The latest version looks much better! Fix the test to check for linux, and > the indentation in the new header file, and I'd say you're good to go! @magicus update ready, with test fix, indentation and remove .file form the linux incubator files. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v5]
On Wed, 13 Apr 2022 13:55:59 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with two additional > commits since the last revision: > > - 8284661: Reproducible assembly builds without relative linking > >Signed-off-by: Andrew Leonard > - 8284661: Reproducible assembly builds without relative linking > >Signed-off-by: Andrew Leonard make/data/autoheaders/assemblyprefix.h line 25: > 23: > 24: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file path > 25: // in NativeCompilation.gmk, this ensures reproducible .debuginfo Actually, this ensures reproducible object file (`.o`) rather than the contents of `.debuginfo`. As far as I remember, `gcc` uses the "value" of `.file` in `.debuginfo`, but `clang` does not. Which is why the path mapping option is still necessary even with `.file` present and with a value stable across builds. Maybe phrase this something like ... this ensures a reproducible object file through a predictable value of the STT_FILE symbol. ? - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v5]
On Thu, 14 Apr 2022 10:13:32 GMT, Maxim Kartashev wrote: >> Andrew Leonard has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - 8284661: Reproducible assembly builds without relative linking >> >>Signed-off-by: Andrew Leonard >> - 8284661: Reproducible assembly builds without relative linking >> >>Signed-off-by: Andrew Leonard > > make/data/autoheaders/assemblyprefix.h line 25: > >> 23: >> 24: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file path >> 25: // in NativeCompilation.gmk, this ensures reproducible .debuginfo > > Actually, this ensures reproducible object file (`.o`) rather than the > contents of `.debuginfo`. As far as I remember, `gcc` uses the "value" of > `.file` in `.debuginfo`, but `clang` does not. Which is why the path mapping > option is still necessary even with `.file` present and with a value stable > across builds. > > Maybe phrase this something like > > ... this ensures a reproducible object file through a predictable value of > the STT_FILE symbol. > > ? @mkartashev thanks. So at the moment we are only using this assembly header for gcc tooling, see NativeCompliation.gmk change. So maybe I change this to specifically state gcc and it's effect on linux debuginfo ? - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v6]
> This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision: 8284661: Reproducible assembly builds without relative linking Signed-off-by: Andrew Leonard - Changes: - all: https://git.openjdk.java.net/jdk/pull/8177/files - new: https://git.openjdk.java.net/jdk/pull/8177/files/4245e704..37d1c3d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=04-05 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8177/head:pull/8177 PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v5]
On Wed, 13 Apr 2022 13:55:59 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with two additional > commits since the last revision: > > - 8284661: Reproducible assembly builds without relative linking > >Signed-off-by: Andrew Leonard > - 8284661: Reproducible assembly builds without relative linking > >Signed-off-by: Andrew Leonard I have successfully tested this PR on all platforms running test/jdk/build/AbsPathsInImage. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v5]
On Thu, 14 Apr 2022 11:13:20 GMT, Andrew Leonard wrote: >> make/data/autoheaders/assemblyprefix.h line 25: >> >>> 23: >>> 24: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file path >>> 25: // in NativeCompilation.gmk, this ensures reproducible .debuginfo >> >> Actually, this ensures reproducible object file (`.o`) rather than the >> contents of `.debuginfo`. As far as I remember, `gcc` uses the "value" of >> `.file` in `.debuginfo`, but `clang` does not. Which is why the path mapping >> option is still necessary even with `.file` present and with a value stable >> across builds. >> >> Maybe phrase this something like >> >> ... this ensures a reproducible object file through a predictable value of >> the STT_FILE symbol. >> >> ? > > @mkartashev thanks. So at the moment we are only using this assembly header > for gcc tooling, see NativeCompliation.gmk change. > So maybe I change this to specifically state gcc and it's effect on linux > debuginfo ? updated - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v5]
On Thu, 14 Apr 2022 12:00:56 GMT, Andrew Leonard wrote: >> @mkartashev thanks. So at the moment we are only using this assembly header >> for gcc tooling, see NativeCompliation.gmk change. >> So maybe I change this to specifically state gcc and it's effect on linux >> debuginfo ? > > updated @andrew-m-leonard Thank you (both for making the change and correcting me wrt the scope of this commit, which is gcc-only). - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v6]
On Thu, 14 Apr 2022 12:07:06 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with one additional > commit since the last revision: > > 8284661: Reproducible assembly builds without relative linking > > Signed-off-by: Andrew Leonard Looks great now! Thanks for pulling this through. - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v7]
> This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision: Trigger checks - Changes: - all: https://git.openjdk.java.net/jdk/pull/8177/files - new: https://git.openjdk.java.net/jdk/pull/8177/files/37d1c3d2..e2dc99cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8177&range=05-06 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8177/head:pull/8177 PR: https://git.openjdk.java.net/jdk/pull/8177
