On Fri, 8 Apr 2022 20:17:52 GMT, Naoto Sato wrote:
>> This is to upgrade the CLDR data from version 39 to version 41 which was
>> released yesterday. The vast majority of the changes are basically replacing
>> the CLDR data, along with tools/testcase alignments. Here is the link to
>> CLDR v41
On Fri, 8 Apr 2022 14:48:41 GMT, Andrew Leonard 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: 0 FILELOCAL DEFAULT
On Fri, 8 Apr 2022 20:17:52 GMT, Naoto Sato wrote:
>> This is to upgrade the CLDR data from version 39 to version 41 which was
>> released yesterday. The vast majority of the changes are basically replacing
>> the CLDR data, along with tools/testcase alignments. Here is the link to
>> CLDR v41
On Fri, 8 Apr 2022 14:57:02 GMT, Magnus Ihse Bursie wrote:
> There's been unnecessary (near) duplication of functionality, and messy
> logic, in the langtools gensrc step, for a long time. (Basically since we got
> rid of the mercurial forest...)
>
> This is a first attempt at cleaning this up
> There's been unnecessary (near) duplication of functionality, and messy
> logic, in the langtools gensrc step, for a long time. (Basically since we got
> rid of the mercurial forest...)
>
> This is a first attempt at cleaning this up. The file
> GensrcCommonLangtools.gmk is removed. This cont
On Fri, 8 Apr 2022 16:59:37 GMT, Erik Joelsson wrote:
>> There's been unnecessary (near) duplication of functionality, and messy
>> logic, in the langtools gensrc step, for a long time. (Basically since we
>> got rid of the mercurial forest...)
>>
>> This is a first attempt at cleaning this up
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's release notes: https://cldr.unicode.org/index/download
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's r
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's r
On Fri, 8 Apr 2022 14:57:02 GMT, Magnus Ihse Bursie wrote:
> There's been unnecessary (near) duplication of functionality, and messy
> logic, in the langtools gensrc step, for a long time. (Basically since we got
> rid of the mercurial forest...)
>
> This is a first attempt at cleaning this up
There's been unnecessary (near) duplication of functionality, and messy logic,
in the langtools gensrc step, for a long time. (Basically since we got rid of
the mercurial forest...)
This is a first attempt at cleaning this up. The file GensrcCommonLangtools.gmk
is removed. This contained three
On Fri, 8 Apr 2022 14:42:34 GMT, Andrew Leonard wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Trigger checks
>
> I am not sure why without the explicit .file directive that the FILE symbol
> in the ELF info co
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Fri, 8 Apr 2022 14:42:34 GMT, Andrew Leonard wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Trigger checks
>
> I am not sure why without the explicit .file directive that the FILE symbol
> in the ELF info co
On Fri, 8 Apr 2022 14:18:50 GMT, Maxim Kartashev wrote:
>> @magicus
>>> Is it possible to pass the ".file" directive on the command line?
>>
>> I don't think so. Your other idea works quite well, though. If you have this
>> in the source
>>
>>.file THIS_FILE
>>
>> and you specify thi
On Fri, 8 Apr 2022 14:16:03 GMT, Maxim Kartashev wrote:
>> @mkartashev Why don't you try building with clang as two different users, in
>> two different directories, and see if the build is non-reproducible without
>> this patch, but is reproducible with it (incl. your suggested change to
>> i
On Fri, 8 Apr 2022 14:11:56 GMT, Magnus Ihse Bursie wrote:
>> I did some experiments both with `gcc` and `clang`. Both respect the `.file`
>> directive and put into the resulting ELF whatever was written after that
>> keyword, so no path mapping is necessary. However, debug information suffers
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Fri, 8 Apr 2022 14:10:05 GMT, Maxim Kartashev wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Trigger checks
>
> I did some experiments both with `gcc` and `clang`. Both respect the `.file`
> directive and pu
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Fri, 8 Apr 2022 13:23:23 GMT, Andrew Leonard wrote:
> 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
Please review these changes to update the security libraries to use sealed
classes. See JEP 409 for more details on sealed classes.
No CSR is required as all the changes are to internal classes. A few classes
that did not have subclasses were simply marked final instead of sealed.
-
On Fri, 8 Apr 2022 13:23:23 GMT, Andrew Leonard wrote:
> @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?
Will that not affect the ability to debug these files, as GDB wo
On Fri, 8 Apr 2022 13:02:00 GMT, Erik Joelsson wrote:
>> Christian Hagedorn has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 60 commits:
>>
>> - Merge branch 'master' into JDK-8242181
>> - Fix build, add GCC flag gdwarf-4 to excl
On Thu, 7 Apr 2022 07:53:38 GMT, Christoph Langer wrote:
> In GitHub Actions the step "Check that all tests executed successfully" will
> be marked as failing when the "Run tests" step did not run but some earlier
> step already failed. This is irritating and it can be corrected by doing the
>
On Thu, 7 Apr 2022 15:29:59 GMT, Magnus Ihse Bursie wrote:
>> In GitHub Actions the step "Check that all tests executed successfully" will
>> be marked as failing when the "Run tests" step did not run but some earlier
>> step already failed. This is irritating and it can be corrected by doing t
On Fri, 8 Apr 2022 13:11:32 GMT, Maxim Kartashev 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 ...
>>> ```
>>>
>>>
On Fri, 8 Apr 2022 12:57:58 GMT, Andrew Leonard wrote:
> 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 fo
On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x
On Fri, 8 Apr 2022 12:43:46 GMT, Maxim Kartashev 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 propaga
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Fri, 8 Apr 2022 12:24:38 GMT, Maxim Kartashev wrote:
> FWIW, I (locally) solved the problem of absolute path names in the compiled
> assembly by adding the `.file` directive. For example:
>
> ```
> --- a/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
> +++ b/src/hotspot/os_cpu/linux
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
> When printing the native stack trace on Linux (mostly done for hs_err files),
> it only prints the method with its parameters and a relative offset in the
> method:
>
> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x7f6e01838110, free
> space=1020k
> Native frames: (J=compiled Jav
On Wed, 26 Jan 2022 14:23:14 GMT, Erik Joelsson wrote:
>> Christian Hagedorn has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java
>>
>>Co-authored-by: Erik Joelsson <375
> When printing the native stack trace on Linux (mostly done for hs_err files),
> it only prints the method with its parameters and a relative offset in the
> method:
>
> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x7f6e01838110, free
> space=1020k
> Native frames: (J=compiled Jav
@magicus thank you for looking at this, in hindsight I should have pinged you
to review this as well.
Technically Erik's approval is enough, but I do appreciate if I can get
at least 24h to have a look at build changes that touches delicate build
logic. It usually takes more than one of us t
On Fri, 8 Apr 2022 09:30:51 GMT, Andrew Leonard wrote:
>> 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-p
On Fri, 8 Apr 2022 08:31:45 GMT, Magnus Ihse Bursie 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
>> hav
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's r
On Fri, 8 Apr 2022 08:14:18 GMT, Magnus Ihse Bursie wrote:
>> It would certainly be possible to identify the objects created from assembly
>> source files based on file extensions, but it wouldn't help. The command
>> line would still be dependent on the current working directory (correctly
>>
On Thu, 7 Apr 2022 20:15:12 GMT, Erik Joelsson wrote:
>> @magicus
>> So I did think about this, and the alternative I think would be to hard code
>> a list of which object files are the output from assembly files, of which
>> there is about a dozen. Unless we could capture somehow the list of
44 matches
Mail list logo
