From: Iain Sandoe <idsandoe@googlemail.com>
To: Jonathan Yong <10walls@gmail.com>
Cc: Radek Barton <radek.barton@microsoft.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
"pinskia@gmail.com" <pinskia@gmail.com>,
Richard Sandiford <richard.sandiford@arm.com>
Subject: Re: [RFC] Either fix or disable SME feature for `aarch64-w64-mingw32` target?
Date: Wed, 10 Jan 2024 09:02:59 +0000 [thread overview]
Message-ID: <46A5B718-2336-4F76-9E21-5DB9C40DF067@googlemail.com> (raw)
In-Reply-To: <452e47e2-7222-46b2-bec1-cb1df812b3ea@gmail.com>
> On 10 Jan 2024, at 08:49, Jonathan Yong <10walls@gmail.com> wrote:
>
> On 1/9/24 19:37, Radek Barton wrote:
>> Hello.
>> I forgot to add the target maintainers to the CC. My apologies for that.
>> Furthermore, I am adding also relevant changes in `libgcc/config/aarch64/lse.S` file to the patch. Originally we wanted to submit those changes separately but after the feedback from Andrew Pinski, it makes sense to add them here. I needed to rename `HIDDEN`, `TYPE`, and `SIZE` macros to `HIDDEN_PO`, `TYPE_PO`, and `SIZE_PO` (pseudo-op) because there is a collision with other macro named `SIZE` in the `lse.S` file.
>> Best regards,
>> Radek
>
> Looks fine to me, but is __ELF__ correct? I am not familiar with pseudo-ops, OK if it is ELF specific when PE is targeted.
>
I suspect that, the end, we really need to generalize this so that ELF, XCOFF, Mach-O etc. are handled. In other places in the tree, typically an “asm.h” (or similar name) is included which contains macros that adjust:
global symbol
local symbol
type
size
(and sometimes .cfi_xxxx-related)
Then the asm sources are adjusted to use those macros throughout, which means that they build correctly for the different object file formats.
You should be able to find a suitable example in other ports which could be updated to cater for aarch64-specific cases.
0.02GBP only, ( I do not have cycles to tackle this myself right now, although I have temporary workarounds in my Darwin branch)
Iain
next prev parent reply other threads:[~2024-01-10 9:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <PR3PR83MB0459E41CA2C7CF4A233A2DA492672@PR3PR83MB0459.EURPRD83.prod.outlook.com>
[not found] ` <PR3PR83MB0459CD0B388EC092D67DCF9E92672@PR3PR83MB0459.EURPRD83.prod.outlook.com>
2024-01-04 13:50 ` Fw: " Radek Barton
2024-01-04 19:11 ` Andrew Pinski
2024-01-05 14:43 ` [EXTERNAL] " Radek Barton
2024-01-09 19:37 ` Radek Barton
2024-01-10 8:49 ` Jonathan Yong
2024-01-10 9:02 ` Iain Sandoe [this message]
2024-01-10 9:13 ` Iain Sandoe
2024-01-10 10:32 ` [EXTERNAL] " Radek Barton
2024-01-11 13:08 ` Richard Sandiford
2024-01-15 16:07 ` Radek Barton
2024-01-15 17:21 ` Radek Barton
2024-01-18 12:06 ` Radek Barton
2024-01-25 17:46 ` Szabolcs Nagy
2024-01-25 17:51 ` Szabolcs Nagy
2024-01-23 15:35 ` Richard Sandiford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46A5B718-2336-4F76-9E21-5DB9C40DF067@googlemail.com \
--to=idsandoe@googlemail.com \
--cc=10walls@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=pinskia@gmail.com \
--cc=radek.barton@microsoft.com \
--cc=richard.sandiford@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).