* Making a syscall before ld.so self-relocation on MIPS
@ 2023-05-17 9:29 Florian Weimer
2023-05-17 19:01 ` Joseph Myers
0 siblings, 1 reply; 4+ messages in thread
From: Florian Weimer @ 2023-05-17 9:29 UTC (permalink / raw)
To: libc-alpha
I'm reviewing HIDDEN_VAR_NEEDS_DYNAMIC_RELOC if they support inline
system calls (without function calls), so that I can make a system call
(mmap actually) before initial self-relocation of the dynamic loader.
So far, it looks good in theory, except on MIPS. First there is MIPS16:
/* There's no MIPS16 syscall instruction, so we go through out-of-line
standard MIPS wrappers. These do use inline snippets below though,
through INTERNAL_SYSCALL_MIPS16. Spilling the syscall number to
memory gives the best code in that case, avoiding the need to save
and restore a static register. */
Is MIPS16 the default in GCC? We don't build for explicitly in
scripts/build-many-glibcs.py.
Without MIPS16, many arguments use out-of-line function calls. But it
seems that the effective relative address range for branches is fairly
large. Maybe we can call a hidden function in ld.so without a
relocation dependency after all?
Thanks,
Florian
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Making a syscall before ld.so self-relocation on MIPS
2023-05-17 9:29 Making a syscall before ld.so self-relocation on MIPS Florian Weimer
@ 2023-05-17 19:01 ` Joseph Myers
2023-05-17 19:30 ` Florian Weimer
0 siblings, 1 reply; 4+ messages in thread
From: Joseph Myers @ 2023-05-17 19:01 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-alpha
On Wed, 17 May 2023, Florian Weimer via Libc-alpha wrote:
> I'm reviewing HIDDEN_VAR_NEEDS_DYNAMIC_RELOC if they support inline
> system calls (without function calls), so that I can make a system call
> (mmap actually) before initial self-relocation of the dynamic loader.
>
> So far, it looks good in theory, except on MIPS. First there is MIPS16:
>
> /* There's no MIPS16 syscall instruction, so we go through out-of-line
> standard MIPS wrappers. These do use inline snippets below though,
> through INTERNAL_SYSCALL_MIPS16. Spilling the syscall number to
> memory gives the best code in that case, avoiding the need to save
> and restore a static register. */
>
> Is MIPS16 the default in GCC? We don't build for explicitly in
> scripts/build-many-glibcs.py.
No, it's not the default; you need to use the -mips16 option.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Making a syscall before ld.so self-relocation on MIPS
2023-05-17 19:01 ` Joseph Myers
@ 2023-05-17 19:30 ` Florian Weimer
2023-05-17 19:41 ` Joseph Myers
0 siblings, 1 reply; 4+ messages in thread
From: Florian Weimer @ 2023-05-17 19:30 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
* Joseph Myers:
> On Wed, 17 May 2023, Florian Weimer via Libc-alpha wrote:
>
>> I'm reviewing HIDDEN_VAR_NEEDS_DYNAMIC_RELOC if they support inline
>> system calls (without function calls), so that I can make a system call
>> (mmap actually) before initial self-relocation of the dynamic loader.
>>
>> So far, it looks good in theory, except on MIPS. First there is MIPS16:
>>
>> /* There's no MIPS16 syscall instruction, so we go through out-of-line
>> standard MIPS wrappers. These do use inline snippets below though,
>> through INTERNAL_SYSCALL_MIPS16. Spilling the syscall number to
>> memory gives the best code in that case, avoiding the need to save
>> and restore a static register. */
>>
>> Is MIPS16 the default in GCC? We don't build for explicitly in
>> scripts/build-many-glibcs.py.
>
> No, it's not the default; you need to use the -mips16 option.
And apparently this is expected to work for building glibc? We have
some support code for it.
I guess I could override that for elf/rtld.c with -mno-mips16. Would it
be okay to do that, and rely on GCC generating a direct bal instruction
for invoking the system call helper?
Thanks,
Florian
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Making a syscall before ld.so self-relocation on MIPS
2023-05-17 19:30 ` Florian Weimer
@ 2023-05-17 19:41 ` Joseph Myers
0 siblings, 0 replies; 4+ messages in thread
From: Joseph Myers @ 2023-05-17 19:41 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-alpha
On Wed, 17 May 2023, Florian Weimer via Libc-alpha wrote:
> * Joseph Myers:
>
> > On Wed, 17 May 2023, Florian Weimer via Libc-alpha wrote:
> >
> >> I'm reviewing HIDDEN_VAR_NEEDS_DYNAMIC_RELOC if they support inline
> >> system calls (without function calls), so that I can make a system call
> >> (mmap actually) before initial self-relocation of the dynamic loader.
> >>
> >> So far, it looks good in theory, except on MIPS. First there is MIPS16:
> >>
> >> /* There's no MIPS16 syscall instruction, so we go through out-of-line
> >> standard MIPS wrappers. These do use inline snippets below though,
> >> through INTERNAL_SYSCALL_MIPS16. Spilling the syscall number to
> >> memory gives the best code in that case, avoiding the need to save
> >> and restore a static register. */
> >>
> >> Is MIPS16 the default in GCC? We don't build for explicitly in
> >> scripts/build-many-glibcs.py.
> >
> > No, it's not the default; you need to use the -mips16 option.
>
> And apparently this is expected to work for building glibc? We have
> some support code for it.
Yes, it's supposed to work for building glibc (without actually being a
different ABI). I haven't tested it for several years.
> I guess I could override that for elf/rtld.c with -mno-mips16. Would it
> be okay to do that, and rely on GCC generating a direct bal instruction
> for invoking the system call helper?
I think using -mno-mips16 for elf/rtld.c is OK.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-05-17 19:41 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-17 9:29 Making a syscall before ld.so self-relocation on MIPS Florian Weimer
2023-05-17 19:01 ` Joseph Myers
2023-05-17 19:30 ` Florian Weimer
2023-05-17 19:41 ` Joseph Myers
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).