* Re: [PATCH v3 0/6] mips: system call table generation support
[not found] ` <20181205063436.kzxgnvgexcgq572k@pburton-laptop>
@ 2018-12-06 12:15 ` Maciej W. Rozycki
2018-12-06 16:19 ` Joseph Myers
0 siblings, 1 reply; 7+ messages in thread
From: Maciej W. Rozycki @ 2018-12-06 12:15 UTC (permalink / raw)
To: Paul Burton
Cc: Firoz Khan, open list:RALINK MIPS ARCHITECTURE, Ralf Baechle,
James Hogan, Greg Kroah-Hartman, Philippe Ombredanne,
Thomas Gleixner, Kate Stewart, y2038 Mailman List, Arnd Bergmann,
Linux Kernel Mailing List, Linux-Arch, Deepa Dinamani,
Marcin Juszkiewicz, libc-alpha
On Wed, 5 Dec 2018, Paul Burton wrote:
> > Could you review this patch series. I would appreciate if you can
> > perform the boot test on the actual platform.
>
> This is looking pretty good to me, so I look forward to v4 with Arnd's
> comments addressed.
>
> I've verified that the sys call tables are identical for both
> 32r2el_defconfig & 64r6el_defconfig before & after this series, and that
> both still boot fine.
I believe this file is used by the glibc build process to retrieve
syscall numbers for glibc's own use as well for <sys/syscall.h>. Has the
change been verified not to break this process?
Cc-ing <libc-alpha@sourceware.org> for information and possible further
input.
Maciej
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 0/6] mips: system call table generation support
2018-12-06 12:15 ` [PATCH v3 0/6] mips: system call table generation support Maciej W. Rozycki
@ 2018-12-06 16:19 ` Joseph Myers
2018-12-06 17:04 ` Maciej W. Rozycki
0 siblings, 1 reply; 7+ messages in thread
From: Joseph Myers @ 2018-12-06 16:19 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Paul Burton, Firoz Khan, open list:RALINK MIPS ARCHITECTURE,
Ralf Baechle, James Hogan, Greg Kroah-Hartman,
Philippe Ombredanne, Thomas Gleixner, Kate Stewart,
y2038 Mailman List, Arnd Bergmann, Linux Kernel Mailing List,
Linux-Arch, Deepa Dinamani, Marcin Juszkiewicz, libc-alpha
On Thu, 6 Dec 2018, Maciej W. Rozycki wrote:
> I believe this file is used by the glibc build process to retrieve
> syscall numbers for glibc's own use as well for <sys/syscall.h>. Has the
> change been verified not to break this process?
>
> Cc-ing <libc-alpha@sourceware.org> for information and possible further
> input.
I'm not sure what "this file" is. The glibc build uses the installed
<asm/unistd.h> (the results of #including it, not any other kind of
processing the file).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 0/6] mips: system call table generation support
2018-12-06 16:19 ` Joseph Myers
@ 2018-12-06 17:04 ` Maciej W. Rozycki
2018-12-06 17:20 ` Joseph Myers
0 siblings, 1 reply; 7+ messages in thread
From: Maciej W. Rozycki @ 2018-12-06 17:04 UTC (permalink / raw)
To: Joseph Myers
Cc: Paul Burton, Firoz Khan, open list:RALINK MIPS ARCHITECTURE,
Ralf Baechle, James Hogan, Greg Kroah-Hartman,
Philippe Ombredanne, Thomas Gleixner, Kate Stewart,
y2038 Mailman List, Arnd Bergmann, Linux Kernel Mailing List,
Linux-Arch, Deepa Dinamani, Marcin Juszkiewicz, libc-alpha
On Thu, 6 Dec 2018, Joseph Myers wrote:
> > I believe this file is used by the glibc build process to retrieve
> > syscall numbers for glibc's own use as well for <sys/syscall.h>. Has the
> > change been verified not to break this process?
> >
> > Cc-ing <libc-alpha@sourceware.org> for information and possible further
> > input.
>
> I'm not sure what "this file" is. The glibc build uses the installed
> <asm/unistd.h> (the results of #including it, not any other kind of
> processing the file).
So how are `SYS_<name>' macros generated that land in <bits/syscall.h>?
Maciej
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 0/6] mips: system call table generation support
2018-12-06 17:04 ` Maciej W. Rozycki
@ 2018-12-06 17:20 ` Joseph Myers
2018-12-06 17:43 ` Maciej W. Rozycki
0 siblings, 1 reply; 7+ messages in thread
From: Joseph Myers @ 2018-12-06 17:20 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Paul Burton, Firoz Khan, open list:RALINK MIPS ARCHITECTURE,
Ralf Baechle, James Hogan, Greg Kroah-Hartman,
Philippe Ombredanne, Thomas Gleixner, Kate Stewart,
y2038 Mailman List, Arnd Bergmann, Linux Kernel Mailing List,
Linux-Arch, Deepa Dinamani, Marcin Juszkiewicz, libc-alpha
On Thu, 6 Dec 2018, Maciej W. Rozycki wrote:
> On Thu, 6 Dec 2018, Joseph Myers wrote:
>
> > > I believe this file is used by the glibc build process to retrieve
> > > syscall numbers for glibc's own use as well for <sys/syscall.h>. Has the
> > > change been verified not to break this process?
> > >
> > > Cc-ing <libc-alpha@sourceware.org> for information and possible further
> > > input.
> >
> > I'm not sure what "this file" is. The glibc build uses the installed
> > <asm/unistd.h> (the results of #including it, not any other kind of
> > processing the file).
>
> So how are `SYS_<name>' macros generated that land in <bits/syscall.h>?
By gen-syscall-h.awk, which generates #ifdef conditionals for each
possible __NR_* name (as listed in syscall-names.list in glibc).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 0/6] mips: system call table generation support
2018-12-06 17:20 ` Joseph Myers
@ 2018-12-06 17:43 ` Maciej W. Rozycki
2018-12-06 18:11 ` Florian Weimer
0 siblings, 1 reply; 7+ messages in thread
From: Maciej W. Rozycki @ 2018-12-06 17:43 UTC (permalink / raw)
To: Joseph Myers
Cc: Paul Burton, Firoz Khan, open list:RALINK MIPS ARCHITECTURE,
Ralf Baechle, James Hogan, Greg Kroah-Hartman,
Philippe Ombredanne, Thomas Gleixner, Kate Stewart,
y2038 Mailman List, Arnd Bergmann, Linux Kernel Mailing List,
Linux-Arch, Deepa Dinamani, Marcin Juszkiewicz, libc-alpha
On Thu, 6 Dec 2018, Joseph Myers wrote:
> > So how are `SYS_<name>' macros generated that land in <bits/syscall.h>?
>
> By gen-syscall-h.awk, which generates #ifdef conditionals for each
> possible __NR_* name (as listed in syscall-names.list in glibc).
I seem to remember having to take extra care with how the three MIPS ABIs
wire the syscalls to get it right in glibc, but I take it then this has
been now addressed reliably enough for the glibc not to care how exactly
<asm/unistd.h> has been arranged.
Given my current level of involvement with the MIPS architecture I take
your word for it and will not investigate it any further. Thanks for your
input.
Maciej
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 0/6] mips: system call table generation support
2018-12-06 17:43 ` Maciej W. Rozycki
@ 2018-12-06 18:11 ` Florian Weimer
2018-12-07 14:49 ` Maciej W. Rozycki
0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2018-12-06 18:11 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Joseph Myers, Paul Burton, Firoz Khan,
open list:RALINK MIPS ARCHITECTURE, Ralf Baechle, James Hogan,
Greg Kroah-Hartman, Philippe Ombredanne, Thomas Gleixner,
Kate Stewart, y2038 Mailman List, Arnd Bergmann,
Linux Kernel Mailing List, Linux-Arch, Deepa Dinamani,
Marcin Juszkiewicz, libc-alpha
* Maciej W. Rozycki:
> On Thu, 6 Dec 2018, Joseph Myers wrote:
>
>> > So how are `SYS_<name>' macros generated that land in <bits/syscall.h>?
>>
>> By gen-syscall-h.awk, which generates #ifdef conditionals for each
>> possible __NR_* name (as listed in syscall-names.list in glibc).
>
> I seem to remember having to take extra care with how the three MIPS ABIs
> wire the syscalls to get it right in glibc, but I take it then this has
> been now addressed reliably enough for the glibc not to care how exactly
> <asm/unistd.h> has been arranged.
This is a fairly recent change (commit
2dba5ce7b8115d6a2789bf279892263621088e74, "<bits/syscall.h>: Use an
arch-independent system call list on Linux", first release with it is
glibc 2.27). This patch is quite backportable; we have put it into our
2.17-derived glibc, and the upstream work was originally driven by
downstream ordering requirements of kernel header and glibc builds.
Glad to see it's useful elsewhere.
The test retains the old <asm/unistd.h>-based macro extraction for
testing purposes, but it needs that only for the actual target
architecture and only the *names*, so it's easy to implement. Before
that, the generation would have to carefully take into account multiple
sub-targets (i386/x86-64/x32 is one of the more complicated scenarios).
Presumably, you saw problem with that part.
Even if you introduce breakage here, it will only affect older glibc
builds. It's not something that application developers would see.
Thanks,
Florian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 0/6] mips: system call table generation support
2018-12-06 18:11 ` Florian Weimer
@ 2018-12-07 14:49 ` Maciej W. Rozycki
0 siblings, 0 replies; 7+ messages in thread
From: Maciej W. Rozycki @ 2018-12-07 14:49 UTC (permalink / raw)
To: Florian Weimer
Cc: Joseph Myers, Paul Burton, Firoz Khan,
open list:RALINK MIPS ARCHITECTURE, Ralf Baechle, James Hogan,
Greg Kroah-Hartman, Philippe Ombredanne, Thomas Gleixner,
Kate Stewart, y2038 Mailman List, Arnd Bergmann,
Linux Kernel Mailing List, Linux-Arch, Deepa Dinamani,
Marcin Juszkiewicz, libc-alpha
On Thu, 6 Dec 2018, Florian Weimer wrote:
> > I seem to remember having to take extra care with how the three MIPS ABIs
> > wire the syscalls to get it right in glibc, but I take it then this has
> > been now addressed reliably enough for the glibc not to care how exactly
> > <asm/unistd.h> has been arranged.
>
> This is a fairly recent change (commit
> 2dba5ce7b8115d6a2789bf279892263621088e74, "<bits/syscall.h>: Use an
> arch-independent system call list on Linux", first release with it is
> glibc 2.27). This patch is quite backportable; we have put it into our
> 2.17-derived glibc, and the upstream work was originally driven by
> downstream ordering requirements of kernel header and glibc builds.
> Glad to see it's useful elsewhere.
Thanks for the pointer, and the work you have done to make this more
robust; it was that that I missed.
> The test retains the old <asm/unistd.h>-based macro extraction for
> testing purposes, but it needs that only for the actual target
> architecture and only the *names*, so it's easy to implement. Before
> that, the generation would have to carefully take into account multiple
> sub-targets (i386/x86-64/x32 is one of the more complicated scenarios).
> Presumably, you saw problem with that part.
Yeah, the MIPS o32/n64/n32 ABI set is a corresponding situation, except
that somewhat longer-lived as we've had support for these three ABIs since
2001, including the ability to concurrently run user executables built for
any of these ABIs under a single 64-bit Linux kernel.
Maciej
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-12-07 14:33 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1543481016-18500-1-git-send-email-firoz.khan@linaro.org>
[not found] ` <CALxhOnjSEp++W5T3Sf0eX+8hPt08ER22M817M-Vhd24_96a_EQ@mail.gmail.com>
[not found] ` <20181205063436.kzxgnvgexcgq572k@pburton-laptop>
2018-12-06 12:15 ` [PATCH v3 0/6] mips: system call table generation support Maciej W. Rozycki
2018-12-06 16:19 ` Joseph Myers
2018-12-06 17:04 ` Maciej W. Rozycki
2018-12-06 17:20 ` Joseph Myers
2018-12-06 17:43 ` Maciej W. Rozycki
2018-12-06 18:11 ` Florian Weimer
2018-12-07 14:49 ` Maciej W. Rozycki
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).