On Wed, 12 Feb 2025 07:31:39 GMT, Matthias Baesken wrote:
> Do you have an example of a bug caused by the issue you mention (and is this
> already documented in the JBS somewhere) ?
I don't believe this is documented anywhere in the issue tracker, I'll do so in
a moment. The bug is an Internal
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag
> so no diff
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore wrote:
> There are a lot of format modifiers that are noisy and unnecessary in the
> code. This change removes the INTX variants. It's not that disruptive even
> for backporting because %z modifier has been available for a long time so
> sho
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Fri, 15 Nov 2024 21:05:21 GMT, Alex Menkov wrote:
> The issue was introduced by
> [JDK-8339289](https://bugs.openjdk.org/browse/JDK-8339289).
> The fix makes `Win32AttachOperationRequest` successor of
> `CHeapObj`, so `Win32AttachOperationRequest` inherits its
> `new` operator
>
> testing:
On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote:
>>> I do wonder if mutex support can be implemented for Windows with
>>> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
>>> would be nice to have. Shame threads.h is not available with some Visual
>>> Studio versi
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase.
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since
On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote:
>>> I do wonder if mutex support can be implemented for Windows with
>>> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
>>> would be nice to have. Shame threads.h is not available with some Visual
>>> Studio versi
On Fri, 8 Nov 2024 13:10:48 GMT, Alexey Semenyuk wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove global memHandle, would've liked to keep it as a comment :(
>
> src/jdk.
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since the last r
On Thu, 7 Nov 2024 08:32:16 GMT, theoweidmannoracle wrote:
>> - Changed several "NULL" in comments to "null"
>> - Changed several `NULL` in code to `nullptr`
>
> theoweidmannoracle has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fix backsli
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov wrote:
> Can someone confirm that use of `__stdcall` has no affect on name
> decorations, as there is no mention here about anything being ignored:
>
> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
>
> I would h
On Thu, 7 Nov 2024 12:08:50 GMT, Aleksey Shipilev wrote:
>> src/hotspot/os/windows/os_windows.cpp line 510:
>>
>>> 508: // Thread start routine for all newly created threads.
>>> 509: // Called with the associated Thread* as the argument.
>>> 510: static unsigned thread_native_entry(void* t) {
>
On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov wrote:
> I think you may be throwing the baby out with the bath water when it comes to
> `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see
> anything that states `__stdcall` is ONLY for 32-bit!
To my knowledge the only thing __
On Tue, 5 Nov 2024 15:05:51 GMT, theoweidmannoracle wrote:
>> - Changed several "NULL" in comments to "null"
>> - Changed several `NULL` in code to `nullptr`
>
> theoweidmannoracle has updated the pull request with a new target base due to
> a merge or a rebase. The incremental webrev excludes t
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since the last r
On Sat, 26 Oct 2024 04:35:09 GMT, Julian Waters wrote:
> I do wonder if mutex support can be implemented for Windows with
> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
> would be nice to have. Shame threads.h is not available with some Visual
> S
On Sun, 27 Oct 2024 06:25:02 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 30 Oct 2024 06:27:22 GMT, Chris Plummer wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request conta
On Wed, 30 Oct 2024 11:19:03 GMT, Magnus Ihse Bursie wrote:
>> src/hotspot/share/adlc/main.cpp line 494:
>>
>>> 492: }
>>> 493:
>>> 494: #if !defined(_WIN32) || defined(_WIN64)
>>
>> Removing the conditionalization is fine for this change. But see also
>> https://bugs.openjdk.org/browse/JDK-
On Sun, 27 Oct 2024 06:25:02 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Tue, 29 Oct 2024 14:37:43 GMT, Aleksey Shipilev wrote:
>> @shipilev There _is_ a way to implement SpinPause on Windows/x64 though, if
>> support is really as simple as a single pause instruction. Should I help
>> implement this separately (After this PR is integrated, to avoid conflicts)?
>
On Tue, 29 Oct 2024 14:44:03 GMT, Magnus Ihse Bursie wrote:
>> I stand corrected: I forgot about Windows/ARM64. To correct myself: Due to a
>> bug, this file, which is meant for Windows/x64, is used by Windows/ARM64
>> instead. The consequences of this are unknown
>
> What bug are you referring
On Mon, 28 Oct 2024 19:25:09 GMT, Aleksey Shipilev wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>> T
On Tue, 29 Oct 2024 06:59:22 GMT, Julian Waters wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build suppor
On Tue, 29 Oct 2024 09:32:21 GMT, David Holmes wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>> This
On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie wrote:
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase.
On Thu, 24 Oct 2024 14:22:28 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 24 Oct 2024 14:22:28 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 24 Oct 2024 14:22:28 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 24 Oct 2024 07:11:16 GMT, David Holmes wrote:
> > the way I did it I'd have to force push
>
> That should not be the case. You can just anti-delta changes.
I did it in a really inefficient way, by checking out all files except for the
files that I wanted to stay. I could not figure out
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has refreshed the contents of this pull request, and previous
commits have been remov
On Wed, 23 Oct 2024 16:51:23 GMT, Chris Plummer wrote:
>> I wasn't sure whether the global memHandle not being used was a bug, so I
>> commented out the local one. I missed the line 88 one because it wasn't
>> flagged. If it really isn't needed I'll remove that one instead
>
> I'm not sure what
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Tue, 22 Oct 2024 18:03:12 GMT, Chris Plummer wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Tue, 22 Oct 2024 09:40:35 GMT, David Holmes wrote:
> > Aren't the dt_shmem and jdwp changes related to HotSpot?
>
> Nope. That's core-svc - the non-hotspot side of serviceability. :)
Oh, well I guess you learn something new everyday :)
-
PR Comment: https://git.openjdk.org/jdk/
On Tue, 22 Oct 2024 01:40:11 GMT, David Holmes wrote:
> > and whatever team is responsible for HotSpot debugging.
>
> I don't see anything hotspot related here.
>
> I think you would be better off splitting this up into distinct issues and
> PRs for different areas. I expect the client team in
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
After 8339120, gcc began catching many different instances of unused code in
the Windows specific codebase. Some of these seem to be bugs. I've taken the
effort to mark out all the relevant globals and locals that trigger the unused
warnings and addressed all of them by commenting out the code a
On Wed, 9 Oct 2024 06:25:07 GMT, Matthias Baesken wrote:
>> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 393:
>>
>>> 391:
>>> 392: hcreate_r(htab_sz, symtab->hash_table);
>>> 393: // guarantee(rslt, "unexpected failure: hcreate_r");
>>
>> The commented out guarantee l
On Sat, 21 Sep 2024 04:19:13 GMT, Kim Barrett wrote:
> Please review this change which removes the class NarrowPtrStruct. The only
> place it was still being used was as the type of CompressedOops::_narrow_oops.
> Instead, we move the members from NarrowPtrStruct directly into
> CompressedOops, f
On Thu, 12 Sep 2024 13:56:42 GMT, Simon Tooke wrote:
>> This PR changes the status of realpath() from a Posix-specific API to a
>> globally available API, i.e. adding it to the "Hotspot Porting API". Code
>> would refer to os::realpath() instead of os::Posix::realpath().
>>
>> This requires t
On Wed, 11 Sep 2024 14:31:43 GMT, Simon Tooke wrote:
>> This PR changes the status of realpath() from a Posix-specific API to a
>> globally available API, i.e. adding it to the "Hotspot Porting API". Code
>> would refer to os::realpath() instead of os::Posix::realpath().
>>
>> This requires t
On Wed, 4 Sep 2024 20:10:54 GMT, Simon Tooke wrote:
>> This PR changes the status of realpath() from a Posix-specific API to a
>> globally available API, i.e. adding it to the "Hotspot Porting API". Code
>> would refer to os::realpath() instead of os::Posix::realpath().
>>
>> This requires th
On Mon, 2 Sep 2024 04:09:19 GMT, David Holmes wrote:
> > This does make me wonder: What if the new method for checking if the VM was
> > statically linked was inlined? Then the problem comes back yet again as the
> > object files need to be recompiled once more. This is possible if Link Time
>
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie wrote:
>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
>> sledgehammer to get rid of some warnings that proliferate in a few areas of
>> the build.
>>
>> We should instead leave -Wunused turned on (as done by -
On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote:
> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (as done by -Wall)
On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote:
> snprintf has been available for all officially and unofficially supported
> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
> forever. snprintf is conforming to C99 since the start when compiling usi
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Sat, 24 Aug 2024 05:06:18 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
he buffer was terminated early, as seen here:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for
> awt and jdk.accessibility, 1 for java.ba
he buffer was terminated early, as seen here:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for
> awt and jdk.accessibility, 1 for java.ba
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Thu, 22 Aug 2024 02:46:34 GMT, David Holmes wrote:
> Sorry but I don't understand the point of changing build-time constructs
> using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the
> result of which is already determined at build time. These are not really
> runtime che
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Tue, 30 Jul 2024 06:54:10 GMT, Kim Barrett wrote:
>> src/hotspot/share/prims/methodHandles.cpp line 439:
>>
>>> 437: default:
>>> 438: fatal("unexpected intrinsic id: %d %s", vmIntrinsics::as_int(iid),
>>> vmIntrinsics::name_at(iid));
>>> 439: return 0;
>>
>> Do we no longer need
On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote:
> Please review this change that removes some uses of literal 0 as a null
> pointer constant in prims code.
>
> Testing: mach5 tier1
Looks Good!
-
Marked as reviewed by jwaters (Committer).
PR Review: https://git.openjdk.org/jd
he buffer was terminated early, as seen here:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for
> awt and jdk.accessibility, 1 for java.ba
On Mon, 15 Jul 2024 16:30:02 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> USe os::snprintf in HotSpot
>
> src/jdk.jdwp.agent/windows/native/libjdwp/util_md
On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote:
> snprintf has been available for all officially and unofficially supported
> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
> forever. snprintf is conforming to C99 since the start when compiling usi
he buffer was terminated early, as seen here:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for
> awt and jdk.accessibility, 1 for java.ba
On Fri, 12 Jul 2024 19:18:09 GMT, Kim Barrett wrote:
> This should be using `os::snprintf` rather than `snprintf`. Rationale is in
> the comment here:
>
> https://github.com/openjdk/jdk/blob/1f6e106b45e5109224e13d70f1a40c9e666ec2ab/src/hotspot/share/runtime/os.cpp#L118-L126
>
> And yes, I know
snprintf has been available for all officially and unofficially supported
compilers for Windows, Visual Studio since version 2015 and gcc since, well,
forever. snprintf is conforming to C99 since the start when compiling using
gcc, and 2015 when using Visual Studio. Since it conforms to C99 and
On Thu, 4 Jul 2024 12:15:09 GMT, Kim Barrett wrote:
> Please review this change to some jvmti tests, which were calling fflush with
> an argument of 0. Most of these are in C++ code, where we change them to use
> nullptr as the argument. A couple are in C, where we change them to use NULL.
> Thi
On Sun, 30 Jun 2024 22:15:34 GMT, Kim Barrett wrote:
> Please review this trivial change to the print_method function in
> test/lib/jdk/test/lib/jvmti/jvmti_common.hpp. It was passing 0 as the FILE*
> argument to fflush, triggering -Wzero-as-null-pointer-constant if that warning
> is enabled. T
On Tue, 11 Jun 2024 18:07:10 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This change ensures we don't get undefined behavior when
>> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
>> `isspace` accepts an `int` argument that "the application shall
o be clarified, as several, ranging
> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason,
> the build system hack in place at the moment to compile the binutils backend
> on Windows is still left in place, for now.
Julian Waters has updated the pull request with
o be clarified, as several, ranging
> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason,
> the build system hack in place at the moment to compile the binutils backend
> on Windows is still left in place, for now.
Julian Waters has updated the pull request with
On Fri, 7 Jun 2024 13:01:15 GMT, SendaoYan wrote:
>> As confusing as they are, unfortunately GitHub UI does not render extra
>> trailing newlines. This is the only one I could find with grepWin.
>
> I find the extra trailing newlines through below shell command:
>
> for i in `find . -iname "Mak
On Fri, 7 Jun 2024 07:26:39 GMT, SendaoYan wrote:
>> test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:
>>
>>> 1: #
>>
>> This file change is dubious:
>> 1. It does not have any trailing whitespace that can fail the skara checks.
>> 2. If the duplicate blank lines in the end of
On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote:
>> Hi all,
>> This PR several extra empty spaces and extra empty lines in several
>> Makefiles. It's trivial fix, no risk.
>>
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional
> commit since the last revi
On Wed, 15 May 2024 13:32:38 GMT, Magnus Ihse Bursie wrote:
> Hi Julian, sorry for not getting back to you.
>
> The problem from my PoV is that this is a very large and intrusive patch in
> the build of the actual product, for a claimed problem in the tangential
> hsdis library. I have not und
On Thu, 9 May 2024 07:50:00 GMT, Julian Waters wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during t
On Thu, 9 May 2024 07:50:00 GMT, Julian Waters wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during t
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently, which
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently, which
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently, which
o be clarified, as several, ranging
> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason,
> the build system hack in place at the moment to compile the binutils backend
> on Windows is still left in place, for now.
Julian Waters has updated the pull request with
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently, which
On Tue, 23 Apr 2024 14:25:22 GMT, Magnus Ihse Bursie wrote:
> There's a huge amount of changes for just hsdis... You might have to separate
> out the infrastructure changes that seem to amount to most of the changes
> here.
>
> This is going to take me a while to get through.
Sorry, it's stil
WIP
This changeset contains hsdis for Windows/gcc Port. It supports both the
binutils and capstone backends, though the LLVM backend is left out due to
compatibility issues encountered during the build. Currently, which gcc
distributions are supported is still to be clarified, as several, rangi
On Mon, 4 Mar 2024 12:58:28 GMT, Claudio Nieder wrote:
> > Could I trouble you to mention what exactly was different?
>
> No trouble at all.
>
> `CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is
> where I checked out OpenJDK)
>
> `CCACHE_SLOPPINESS` has the value `pc
On Mon, 4 Mar 2024 11:28:02 GMT, Magnus Ihse Bursie wrote:
> > I wonder if it's the SetupToolchain changes that has caused this. ccache is
> > collapsed into CC and CXX to my knowledge
>
> Yeah, it must have been. Would you like to take a look at it? Otherwise I'll
> file a bug and fix it. Bre
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>
On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote:
> Please review this change that renames some test .h files to .hpp. These
> files contain C++ code and should be named accordingly. Some of them contain
> uses of NULL, which we change to nullptr.
>
> The renamed files are:
>
> test/hotspo
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>
On Tue, 27 Feb 2024 11:09:26 GMT, Magnus Ihse Bursie wrote:
> > can we get rid of LDCXX?
>
> Yeah, that is something I plan to look into. Linking C++ object files with
> gcc will fail; and it might be that linking pure C with g++ might be
> problematic. If this is the case, I hope we can at le
1 - 100 of 169 matches
Mail list logo
