On Wed, 2 Apr 2025, Martin Storsjö wrote:
On Fri, 29 Nov 2024, LIU Hao wrote:
在 2024-11-29 23:50, Jonathan Wakely 写道:
It looks like your patch is against gcc-14 not trunk, the
GLIBCXX_15.1.0 version is already there.
Sorry, I mean GLIBCXX_3.4.34 for 15.1.0
Oops that's what I used to
On Fri, 29 Nov 2024, LIU Hao wrote:
在 2024-11-29 23:50, Jonathan Wakely 写道:
It looks like your patch is against gcc-14 not trunk, the
GLIBCXX_15.1.0 version is already there.
Sorry, I mean GLIBCXX_3.4.34 for 15.1.0
Oops that's what I used to test the patch. Reapplied to master now.
Ping -
On Tue, 12 Nov 2024, Richard Sandiford wrote:
Evgeny Karpov writes:
Hello,
Thank you for reviewing v2!
v3 addresses all comments on v2.
Changes in v3:
- Refactor implementation for the offset limit extension in
"symbol + offset" from 1MB to 16MB.
- Apply HOST_WIDE_INT_PRINT_UNSIGNED in ASM
On Thu, 19 Sep 2024, Richard Sandiford wrote:
Martin Storsjö writes:
On Thu, 12 Sep 2024, Evgeny Karpov wrote:
The current binutils implementation does not support offset up to 4GB in
IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
This is related to differences in ELF and
On Thu, 12 Sep 2024, Evgeny Karpov wrote:
Thursday, September 12, 2024
Martin Storsjö wrote:
This looks very reasonable - I presume this will make sure that you only
use the other code form if the offset actually is larger than 1 MB.
For the case when the offset actually is larger than 1 MB
On Thu, 12 Sep 2024, Evgeny Karpov wrote:
The current binutils implementation does not support offset up to 4GB in
IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
This is related to differences in ELF and COFF relocation records.
Yes, I agree.
But I would not consider this a
On Fri, 6 Sep 2024, Evgeny Karpov wrote:
Friday, September 6, 2024
Martin Storsjö wrote:
Sorry, but no.
You can't just redefine how relocations in your object file format works,
just because you feel like it.
This patch changes how symbol with offset will be emitted.
It will change:
On Fri, 6 Sep 2024, Evgeny Karpov wrote:
aarch64.cc has been updated to prevent emitting "symbol + offset"
for SYMBOL_SMALL_ABSOLUTE for the PECOFF target. "symbol + offset"
cannot be used in relocations for aarch64-w64-mingw32 due to
relocation requirements.
Instead, it will adjust the address
On Thu, 5 Sep 2024, Evgeny Karpov wrote:
Monday, September 2, 2024
Martin Storsjö
The patch adds support for weak references. The original MinGW
implementation targets ix86, which handles weak symbols differently
compared to AArch64.
Please clarify this statement.
Here is an explanation
On Wed, 4 Sep 2024, Evgeny Karpov wrote:
Monday, September 4, 2024
Martin Storsjö wrote:
compilation time
adrp x0, symbol + 256
9000 adrp x0, 0
As the symbol offset is 256, you will need to encode the offset "256" in
the instruction immediate field. Not "256 >
On Wed, 4 Sep 2024, Martin Storsjö wrote:
On Wed, 4 Sep 2024, Evgeny Karpov wrote:
Monday, September 4, 2024
Martin Storsjö wrote:
Let's consider the following example, when symbol is located at 3072.
1. Example without the fix
compilation time
adrp x0, (3072 + 256) & ~0x
On Wed, 4 Sep 2024, Evgeny Karpov wrote:
Monday, September 4, 2024
Martin Storsjö wrote:
Let's consider the following example, when symbol is located at 3072.
1. Example without the fix
compilation time
adrp x0, (3072 + 256) & ~0xFFF // x0 = 0
add x0, x0, (3072 + 256
On Wed, 4 Sep 2024, Evgeny Karpov wrote:
Monday, September 2, 2024
Martin Storsjö wrote:
The only non-obvious thing, is that for IMAGE_REL_ARM64_PAGEBASE_REL21,
i.e. "adrp" instructions, the immediate that gets stored in the
instruction, is the byte offset to the symbol.
After lin
On Mon, 2 Sep 2024, Evgeny Karpov wrote:
The patch adds support for weak references. The original MinGW
implementation targets ix86, which handles weak symbols differently
compared to AArch64.
Please clarify this statement.
There is no difference between architectures with respect to how weak
On Mon, 2 Sep 2024, Evgeny Karpov wrote:
aarch64.cc has been updated to prevent emitting "symbol + offset"
for SYMBOL_SMALL_ABSOLUTE for the PECOFF target. "symbol + offset"
cannot be used in relocations for aarch64-w64-mingw32 due to
relocation requirements.
What relocation requirements are t
On Mon, 18 Mar 2024, Fangrui Song wrote:
LLVM has had an aarch64 mingw ABI support for a long time. Does this
patch series introduce a different ABI?
If yes, do you have a summary?
This patchset in itself does not reach ABI compatibility with the
preexisting aarch64 mingw ecosystem - but this
On Fri, 23 Feb 2024, Richard Sandiford wrote:
Are there two distinct ABIs for aarch64-*-mingw*? Or are these
distinctions ignored on aarch64 and just retained for compatibility?
On Windows on AArch64, the calling convention normally matches regular
AAPCS64 - so the ms_abi attribute normally
On Tue, 25 Oct 2022, Mark Harmstone wrote:
On 24/10/22 12:08, Martin Storsjö wrote:
Hmm, what does this end up passing to the linker in the end - does it just
pass "-pdb="? (What does the "*" parameter do here?) If that's the case -
that sounds reasonable - assuming
On Mon, 24 Oct 2022, Mark Harmstone wrote:
Both current lld and the next version of ld have an option -pdb, which
creates a PDB file which Microsoft's debuggers can use. This patch adds
a -gcodeview option, which passes this to the linker.
I do intend to expand this so it also creates the .debu
On Wed, 11 May 2022, Joseph Myers wrote:
I'd also like to check that "if mingw-w64 is configured to target UCRT" is
not something that is necessarily known when GCC is built or from the
command-line options passed to GCC. Because ideally one might expect the
TARGET_OVERRIDES_FORMAT_ATTRIBUTES /
This is similar to what was done in
eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to
STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and
BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and
BOOT_CFLAGS).
2021-04-09 Martin Storsjö
config/Chan
On Fri, 6 Nov 2020, Jeff Law wrote:
On 9/8/20 9:34 AM, Martin Storsjö wrote:
Hi,
On Tue, 8 Sep 2020, Kirill Müller wrote:
Thanks for the heads up. The coincidence is funny -- a file that
hasn't been touched for years.
I think we both may originally be triggered from the same guy a
On Fri, 6 Nov 2020, Liu Hao via Gcc-patches wrote:
在 2020/10/29 下午3:56, Liu Hao 写道:
I forward it here for comments.
Basing on the behavior of both GCC and Clang, `__cxa_thread_atexit` is used to
register the
destructor of thread_local objects directly, suggesting the first parameter
should h
Hi,
On Tue, 8 Sep 2020, Kirill Müller wrote:
I haven't actually tested if the cfa value (ms_context.Rsp) is valid, I also
see no reason why it shouldn't be.
What does it take for your patch to be accepted? What's the minimum gcc
version where it will be available?
I'm not a maintainer nor a
Hi,
On Tue, 8 Sep 2020, Kirill Müller wrote:
Thanks for the heads up. The coincidence is funny -- a file
that hasn't been touched for years.
I think we both may originally be triggered from the same guy asking
around in different places about implementations of _Unwind_Backtrace for
windows
by _Unwind_GetIP
and _Unwind_GetCFA, to allow using these functions from the
callacb to inspect the state at each stack frame.
2020-09-08 Martin Storsjö
libgcc/Changelog:
* unwind-seh.c (_Unwind_Backtrace): Set the ra and cfa pointers
before calling the callback.
---
libgcc
Hi,
On Mon, 7 Sep 2020, Kirill Müller via Gcc-patches wrote:
As requested, attaching a patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948. This solves a problem
with _Unwind_Backtrace() on mingw64 + SEH.
What a coincidence - I actually sent a patch for the exact same thing
last we
On Tue, 8 Sep 2020, Jakub Jelinek wrote:
On Tue, Sep 08, 2020 at 12:16:08PM +0100, Richard Sandiford wrote:
Are platform maintainers allowed to push general changes like these? If
so I can push soon.
Yeah, anyone with commit access can push an approved patch.
I've pushed this one yesterday
On Tue, 1 Sep 2020, Martin Storsjö wrote:
Previously, the SEH version of _Unwind_Backtrace did unwind
the stack and call the provided callback function as intended,
but there was little the caller could do within the callback to
actually get any info about that particular level in the unwind
Hi,
On Fri, 4 Sep 2020, Jakub Jelinek wrote:
On Tue, Sep 01, 2020 at 04:01:42PM +0300, Martin Storsjö wrote:
This fixes compilation of codepaths for dos-like filesystems
with Clang. When built with clang, it treats C input files as C++
when the compiler driver is invoked in C++ mode, triggeri
_Unwind_GetIP, to allow
using this function to inspect the state within the callback,
before calling the callback function.
2020-09-01 Martin Storsjö
libgcc/Changelog:
* unwind-seh.c (_Unwind_Backtrace): Set the ra pointer before
calling the callback.
---
libgcc/unwind-seh.c | 2 ++
1
.
This matches similar variables outside of the ifdefs for dos-like
path handling.
2020-09-01 Martin Storsjö
gcc/Changelog:
* dwarf2out.c (file_name_acquire): Make a strchr return value
pointer to const.
libcpp/Changelog:
* files.c (remap_filename): Make a strchr return
32 matches
Mail list logo
