From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Segher Boessenkool <segher@kernel.crashing.org>,
Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org,
Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org,
Nicholas Piggin <npiggin@gmail.com>
Subject: Re: powerpc Linux scv support and scv system call ABI proposal
Date: Thu, 30 Jan 2020 14:04:51 -0300 [thread overview]
Message-ID: <f46bafbd-c553-565a-38a4-73d81cc5a8d2@linaro.org> (raw)
In-Reply-To: <20200130135030.GV22482@gate.crashing.org>
On 30/01/2020 10:50, Segher Boessenkool wrote:
> Hi again,
>
> On Thu, Jan 30, 2020 at 01:03:53PM +0100, Florian Weimer wrote:
>>> This is why that *is* the only supported use. The documentation could
>>> use a touch-up, I think. Unless we still have problems here?
>>
>> I really don't know. GCC still has *some* support for the old behavior,
>> though.
>
> No. No support. It still does some of the same things, but that can
> change (and probably should). But this hasn't been supported since the
> dark ages, and the documentation has become gradually more explicit
> about it.
>
I think this might be related to an odd sparc32 issue I am seeing with
newer clock_nanosleep. The expanded code is:
--
register long err __asm__("g1"); // INTERNAL_SYSCALL_DECL (err)
r = ({ // r = INTERNAL_SYSCALL_CANCEL (...)
long int sc_ret;
if (SINGLE_THREAD_P)
sc_ret = INTERNAL_SYSCALL_CALL (__VA_ARGS__);
else
{
int sc_cancel_oldtype = __libc_enable_asynccancel ();
sc_ret = INTERNAL_SYSCALL_CALL (__VA_ARGS__); // It issues the syscall with the asm (...)
__librt_disable_asynccancel (sc_cancel_oldtype);
}
sc_ret;
});
if ((void) (val), __builtin_expect((err) != 0, 0)) // if (! INTERNAL_SYSCALL_ERROR_P (r, err))
return 0;
if ((-(val)) != ENOSYS) // if (INTERNAL_SYSCALL_ERRNO (r, err) != ENOSYS)
return ((-(val))); // return INTERNAL_SYSCALL_ERRNO (r, err);
[...]
r = ({ // r = INTERNAL_SYSCALL_CANCEL (...)
[...]
)}
if ((void) (val), __builtin_expect((err) != 0, 0)) // if (! INTERNAL_SYSCALL_ERROR_P (r, err))
{
[...]
}
return ((void) (val), __builtin_expect((err) != 0, 0)) // return (INTERNAL_SYSCALL_ERROR_P (r, err)
? ((-(val))) : 0; // ? INTERNAL_SYSCALL_ERRNO (r, err) : 0);
--
It requires that 'err' (assigned to 'g1') be value propagated over
functions calls and over different scopes, which I take from your
explanation is not supported and fragile. It also seems that if I
move the __libc_enable_* calls before 'err' initialization and after
its usage the code seems to works, but again it seems this usage
is not really supported on gcc.
So it seems that the current usage of 'INTERNAL_SYSCALL_DECL' and
'INTERNAL_SYSCALL_ERROR_P' are fragile if the architecture *does*
use the 'err' variable and it is defined a register alias (which
its the case only for sparc currently).
Although a straightforward for sparc would be redefine
INTERNAL_SYSCALL_DECL to not use a register alias, I still think
we should just follow Linux kernel ABI convention where value in
the range between -4095 and -1 indicates an error and handle any
specific symbols that might not strictly follow it with an
arch-specific implementation (as we do for lseek on x32 and
mips64n32). It would allow cleanup a lot of code and avoid such
pitfalls.
next prev parent reply other threads:[~2020-01-30 17:07 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-28 10:50 powerpc Linux scv support and scv system call ABI proposal Nicholas Piggin
2020-01-28 13:09 ` Florian Weimer
2020-01-28 14:05 ` Nicholas Piggin
2020-01-28 15:40 ` Segher Boessenkool
2020-01-28 16:04 ` Florian Weimer
2020-01-28 20:01 ` Segher Boessenkool
2020-01-29 16:19 ` Florian Weimer
2020-01-29 16:29 ` Segher Boessenkool
2020-01-29 17:02 ` Florian Weimer
2020-01-29 17:51 ` Segher Boessenkool
2020-01-30 10:42 ` Florian Weimer
2020-01-30 11:25 ` Segher Boessenkool
2020-01-30 12:03 ` Florian Weimer
2020-01-30 13:50 ` Segher Boessenkool
2020-01-30 17:04 ` Adhemerval Zanella [this message]
2020-01-30 21:41 ` Segher Boessenkool
2020-01-31 11:30 ` Adhemerval Zanella
2020-01-31 11:55 ` Segher Boessenkool
2020-01-28 15:58 ` Florian Weimer
2020-01-29 4:41 ` Nicholas Piggin
2020-01-28 17:26 ` Adhemerval Zanella
2020-01-29 4:58 ` Nicholas Piggin
2020-01-29 13:20 ` Segher Boessenkool
2020-01-29 15:51 ` Tulio Magno Quites Machado Filho
2020-02-19 11:03 ` Nicholas Piggin
2020-01-28 22:14 ` Joseph Myers
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=f46bafbd-c553-565a-38a4-73d81cc5a8d2@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=segher@kernel.crashing.org \
--cc=tuliom@linux.ibm.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 NNTP newsgroup(s).