Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1aba2d75-a725-5b07-d567-b04607c3bfda@loongson.cn>
Date: Thu, 12 Mar 2026 09:51:40 +0800
From: lixing <lixing@...ngson.cn>
To: Rich Felker <dalias@...c.org>
Cc: James Y Knight <jyknight@...gle.com>, musl@...ts.openwall.com,
 wanghongliang@...ngson.cn, musl@...ts.openwall.com
Subject: Re: [PATCH] loongarch64: Add lsx and lasx regset definition


在 2026/3/12 上午12:24, Rich Felker 写道:
> On Wed, Mar 11, 2026 at 10:49:15AM -0400, James Y Knight wrote:
>> On Wed, Mar 11, 2026 at 12:07 AM Rich Felker <dalias@...c.org> wrote:
>>> On Tue, Sep 10, 2024 at 09:17:57AM +0800, Xing Li wrote:
>>>> Fix the upstream binutils-gdb building error caused by
>>>> the lack of lsx and lasx regset definition.
>>>> ---
>>>>   arch/loongarch64/bits/user.h | 12 ++++++++++++
>>>>   1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
>>>> index fd9b7b22..10e1be45 100644
>>>> --- a/arch/loongarch64/bits/user.h
>>>> +++ b/arch/loongarch64/bits/user.h
>>>> @@ -22,3 +22,15 @@ typedef union {
>>>>        float f;
>>>>   } elf_fpreg_t;
>>>>   typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>>>> +
>>>> +typedef union
>>>> +{
>>>> +     double d[2];
>>>> +     float f[4];
>>>> +} elf_lsxregset_t[32] __attribute__((__aligned__(16)));
>>>> +
>>>> +typedef union
>>>> +{
>>>> +     double d[4];
>>>> +     float f[8];
>>>> +} elf_lasxregset_t[32] __attribute__((__aligned__(32)));
>>>> --
>>>> 2.27.0
>>> I don't like having the alignment directive bound to the whole type
>>> like this where it's depending on weird GNUC-isms that can't be
>>> represented in standard C alignas, but I think it's ok for now and we
>>> can find a better way to express it later if needed. I know this is
>>> another patch that distros have been carrying for a long time so I'd
>>> like to merge it for release.
>>
>> That code looks weird. Why does it apply the alignment attribute on
>> the _array_ type, rather than the union type? E.g. why is this not
>> just:
>>
>> typedef union
>> {
>>       double d[2];
>>       float f[4];
>> } __attribute__((__aligned__(16))) elf_lsxregset_t[32];
> I'm not sure how GNU C __attribute__((__aligned__(...))) even binds,
> which is part of why I don't like it and prefer the clearer ISO C
> form. But..
>
>> And once you have that, it's easy to take it one step further and move
>> the alignment onto the union field, at which point you can have
>> standard C code:
>>
>> typedef union
>> {
>>       _Alignas(16) double d[2];
>>       _Alignas(16) float f[4];
>> } elf_lsxregset_t[32];
> Does that work? Or would that be trying to apply the alignment to
> double where the alignment is larger than the type and thereby
> invalid? This is totally on me, but I don't understand well how the
> binding works.

I've made a simple test on my 3A5000 platform,  The modification seems work

with this situation, each lsxregset and lasxregset array member aligned 
to16/32.


thanks.

> Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.