* Upstreaming the glibc Hurd port
@ 2018-01-18 12:39 Florian Weimer
2018-01-18 12:45 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Florian Weimer @ 2018-01-18 12:39 UTC (permalink / raw)
To: Samuel Thibault, Thomas Schwinge; +Cc: GNU C Library
As far as I understand it, the Hurd port of glibc is currently mostly a
downstream affair, maintained in the Debian archive. The current
upstream tree does not build, even natively on the Hurd itself.
What would be necessary to get it into a state that in can be built with
a cross-compiler, perhaps even using build-many-glibcs.py? Are FSF
copyright assignments in place for all the relevant patches? Is it just
a matter of someone doing the work of upstreaming all the existing patches?
I'm asking because we may want to implement rather far-reaching dynamic
linker and a thread library integration changes, and having a buildable
in-tree port for Hurd would make it at least possible to ensure that it
keeps building, and that we do not make choices which are very difficult
to mirror on the Hurd side.
If we cannot resolve this is in the coming months, I think we should
seriously consider a removal of the Hurd port, I'm afraid.
Thanks,
Florian
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 12:39 Upstreaming the glibc Hurd port Florian Weimer
@ 2018-01-18 12:45 ` Samuel Thibault
2018-01-18 12:58 ` Florian Weimer
2018-01-18 13:47 ` Joseph Myers
0 siblings, 2 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-01-18 12:45 UTC (permalink / raw)
To: Florian Weimer, bug-hurd; +Cc: Thomas Schwinge, GNU C Library
Florian Weimer, on jeu. 18 janv. 2018 13:39:51 +0100, wrote:
> Is it just a matter of someone doing the work of upstreaming all the
> existing patches?
It's mostly that, yes.
> If we cannot resolve this is in the coming months, I think we should
> seriously consider a removal of the Hurd port, I'm afraid.
Ok, then I can take the time to do it, but as usual it'll be at the
expense of other Hurd activities, e.g. the obvious Meltdown/Spectre
issues, etc.
Unless bug-hurd people actually help me with it.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 12:45 ` Samuel Thibault
@ 2018-01-18 12:58 ` Florian Weimer
2018-01-18 13:47 ` Joseph Myers
1 sibling, 0 replies; 87+ messages in thread
From: Florian Weimer @ 2018-01-18 12:58 UTC (permalink / raw)
To: bug-hurd, Thomas Schwinge, GNU C Library
On 01/18/2018 01:45 PM, Samuel Thibault wrote:
> Florian Weimer, on jeu. 18 janv. 2018 13:39:51 +0100, wrote:
>> Is it just a matter of someone doing the work of upstreaming all the
>> existing patches?
>
> It's mostly that, yes.
Good to know, thanks.
The question is how we can do this incrementally (so that others can
contribute), considering that is currently not exactly easy to set up
and maintain a development environment to validate the changes.
>> If we cannot resolve this is in the coming months, I think we should
>> seriously consider a removal of the Hurd port, I'm afraid.
>
> Ok, then I can take the time to do it, but as usual it'll be at the
> expense of other Hurd activities, e.g. the obvious Meltdown/Spectre
> issues, etc.
Information leakage and microkernels are certainly an interesting
research topic. Message passing results in very different security
considerations.
> Unless bug-hurd people actually help me with it.
I have repeatedly suggested that the FSF uses the toolchain fund to pay
for this work. I do not know there was under serious consideration (or
if the suggestion even made it to the FSF).
Thanks,
Florian
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 12:45 ` Samuel Thibault
2018-01-18 12:58 ` Florian Weimer
@ 2018-01-18 13:47 ` Joseph Myers
2018-01-18 13:52 ` Joseph Myers
` (2 more replies)
1 sibling, 3 replies; 87+ messages in thread
From: Joseph Myers @ 2018-01-18 13:47 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Florian Weimer, bug-hurd, Thomas Schwinge, GNU C Library
Please note (as a reminder from past discussions) that the Hurd libpthread
will need to be included as part of glibc, much like NPTL is a
fully-integrated part of glibc - not a separate package (support for
add-ons has been removed from glibc). (I'd also suggest that it *not* use
a top-level directory called simply "libpthread" or similar without
mention of Hurd, as that would be too confusing to people looking at the
source tree for pthreads for other platforms.)
Also as per previous discussions: Hurd port maintainers can put in changes
to Hurd-specific files at any time (regardless of release freeze state)
until the port is actually working. All the usual coding standards of
course apply, and changes to files that might affect non-Hurd may need
review and not be appropriate at some times, depending on freeze state and
the risks associated with such patches.
In my view, build-many-glibcs.py support for Hurd would be appropriate
even before the Hurd port builds (and certainly before it cleanly passes
the compilation tests). That support will definitely need patch review.
Before Hurd support is fully integrated in glibc, I'd encourage having a
branch *in the glibc repository* that contains such support, so we can
more readily see what the changes yet to be merged are (and possibly
comment on issues that will need addressing when integrating them in
glibc).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 13:47 ` Joseph Myers
@ 2018-01-18 13:52 ` Joseph Myers
2018-01-18 13:59 ` Samuel Thibault
2018-01-18 13:58 ` Samuel Thibault
2018-01-18 14:33 ` Samuel Thibault
2 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-01-18 13:52 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Florian Weimer, bug-hurd, Thomas Schwinge, GNU C Library
Incidentally, Samuel did post the Hurd TLS support three years ago
<https://sourceware.org/ml/libc-alpha/2015-02/msg00139.html>. Roland's
review comments should of course be considered, though the current Hurd
port maintainers are free to decide they disagree with particular aspects
of those comments.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 13:47 ` Joseph Myers
2018-01-18 13:52 ` Joseph Myers
@ 2018-01-18 13:58 ` Samuel Thibault
2018-01-18 14:03 ` Joseph Myers
2018-01-18 14:22 ` Thomas Schwinge
2018-01-18 14:33 ` Samuel Thibault
2 siblings, 2 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-01-18 13:58 UTC (permalink / raw)
To: Joseph Myers; +Cc: Florian Weimer, bug-hurd, Thomas Schwinge, GNU C Library
Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +0000, wrote:
> Please note (as a reminder from past discussions) that the Hurd libpthread
> will need to be included as part of glibc, much like NPTL is a
> fully-integrated part of glibc - not a separate package (support for
> add-ons has been removed from glibc).
Sure, I had to do that work for fixing the build of the
2.26.9000+20180108.401311cf-0experimental0 Debian snapshot
> Also as per previous discussions: Hurd port maintainers can put in changes
> to Hurd-specific files at any time
Sure!
> All the usual coding standards of course apply,
And that's were I haven't received help so far.
> In my view, build-many-glibcs.py support for Hurd would be appropriate
> even before the Hurd port builds (and certainly before it cleanly passes
> the compilation tests). That support will definitely need patch review.
>
> Before Hurd support is fully integrated in glibc, I'd encourage having a
> branch *in the glibc repository* that contains such support, so we can
> more readily see what the changes yet to be merged are (and possibly
> comment on issues that will need addressing when integrating them in
> glibc).
I can pile-commit what we currently have, with all the XXXs, FIXMEs,
etc., if that can help the glibc side.
But the actual discussion of changes is what takes time, and bug-hurd
people have to actually help me with it (or at least unload from me the
coding standards and ChangeLog parts) if they want it to happen fast
enough.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 13:52 ` Joseph Myers
@ 2018-01-18 13:59 ` Samuel Thibault
0 siblings, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-01-18 13:59 UTC (permalink / raw)
To: Joseph Myers; +Cc: Florian Weimer, bug-hurd, Thomas Schwinge, GNU C Library
Joseph Myers, on jeu. 18 janv. 2018 13:52:32 +0000, wrote:
> Incidentally, Samuel did post the Hurd TLS support three years ago
> <https://sourceware.org/ml/libc-alpha/2015-02/msg00139.html>. Roland's
> review comments should of course be considered,
Yes, it has been on my TODO list for as long, hoping that perhaps
somebody could help with it, at least on the coding style part. That
hasn't materialized.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 13:58 ` Samuel Thibault
@ 2018-01-18 14:03 ` Joseph Myers
2018-01-28 18:40 ` Samuel Thibault
2018-01-18 14:22 ` Thomas Schwinge
1 sibling, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-01-18 14:03 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Florian Weimer, bug-hurd, Thomas Schwinge, GNU C Library
On Thu, 18 Jan 2018, Samuel Thibault wrote:
> > Before Hurd support is fully integrated in glibc, I'd encourage having a
> > branch *in the glibc repository* that contains such support, so we can
> > more readily see what the changes yet to be merged are (and possibly
> > comment on issues that will need addressing when integrating them in
> > glibc).
>
> I can pile-commit what we currently have, with all the XXXs, FIXMEs,
> etc., if that can help the glibc side.
I think having such a branch (rebased from time to time, especially as
Hurd changes make their way into master or get cleaned up for issues
raised, so it doesn't fall too far behind master) would be helpful so we
can see the changes and quite likely point out global issues to be
addressed throughout.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 13:58 ` Samuel Thibault
2018-01-18 14:03 ` Joseph Myers
@ 2018-01-18 14:22 ` Thomas Schwinge
2018-01-18 14:27 ` Samuel Thibault
2018-01-18 15:14 ` Samuel Thibault
1 sibling, 2 replies; 87+ messages in thread
From: Thomas Schwinge @ 2018-01-18 14:22 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Florian Weimer, bug-hurd, GNU C Library, Joseph Myers
Hi!
Despite my good intentions, in the past year (or even longer...) I failed
to allocate sufficient time to do any substantial work on the Hurd side,
but I'll now allocate time to at least help with...
On Thu, 18 Jan 2018 14:57:58 +0100, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +0000, wrote:
> > All the usual coding standards of course apply,
>
> And that's were I haven't received help so far.
... that. (Plus the GDB stuff I promised to look into.)
> I can pile-commit what we currently have, with all the XXXs, FIXMEs,
> etc., if that can help the glibc side.
I'm not sure if that's a useful thing to spend time on, right now. I
think it'll be better if we first integrate into glibc upstream the
changes that are non-controversial on our own side, which only touch Hurd
code, etc. Then, for the rest of the changes, those which also touch
generic glibc code, we should then discuss these individually.
> But the actual discussion of changes is what takes time, and bug-hurd
> people have to actually help me with it (or at least unload from me the
> coding standards and ChangeLog parts) if they want it to happen fast
> enough.
ACK.
Grüße
Thomas
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 14:22 ` Thomas Schwinge
@ 2018-01-18 14:27 ` Samuel Thibault
2018-01-18 15:14 ` Samuel Thibault
1 sibling, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-01-18 14:27 UTC (permalink / raw)
To: Thomas Schwinge; +Cc: Florian Weimer, bug-hurd, GNU C Library, Joseph Myers
Thomas Schwinge, on jeu. 18 janv. 2018 15:22:09 +0100, wrote:
> > I can pile-commit what we currently have, with all the XXXs, FIXMEs,
> > etc., if that can help the glibc side.
>
> I'm not sure if that's a useful thing to spend time on, right now. I
> think it'll be better if we first integrate into glibc upstream the
> changes that are non-controversial on our own side, which only touch Hurd
> code, etc. Then, for the rest of the changes, those which also touch
> generic glibc code, we should then discuss these individually.
Note that I didn't mean all patches, just the ones needed for building
glibc.
Yes, the discussion has to happen, we can't fast-forward that. But
putting the stuff on a branch, so people can have a look if they want to
and track the progress, can be useful.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 13:47 ` Joseph Myers
2018-01-18 13:52 ` Joseph Myers
2018-01-18 13:58 ` Samuel Thibault
@ 2018-01-18 14:33 ` Samuel Thibault
2018-01-18 15:24 ` Joseph Myers
2 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-01-18 14:33 UTC (permalink / raw)
To: Joseph Myers; +Cc: Florian Weimer, bug-hurd, Thomas Schwinge, GNU C Library
Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +0000, wrote:
> (I'd also suggest that it *not* use a top-level directory called
> simply "libpthread" or similar without mention of Hurd, as that would
> be too confusing to people looking at the source tree for pthreads for
> other platforms.)
Sure :)
kFreeBSD/GNU used fbtl (FreeBSD Thread Library), perhaps htl? (Hurd
Thread Library)
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 14:22 ` Thomas Schwinge
2018-01-18 14:27 ` Samuel Thibault
@ 2018-01-18 15:14 ` Samuel Thibault
2018-01-18 15:35 ` Joseph Myers
1 sibling, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-01-18 15:14 UTC (permalink / raw)
To: Thomas Schwinge; +Cc: Florian Weimer, bug-hurd, GNU C Library, Joseph Myers
Thomas Schwinge, on jeu. 18 janv. 2018 15:22:09 +0100, wrote:
> Despite my good intentions, in the past year (or even longer...) I failed
> to allocate sufficient time to do any substantial work on the Hurd side,
> but I'll now allocate time to at least help with...
>
> On Thu, 18 Jan 2018 14:57:58 +0100, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +0000, wrote:
> > > All the usual coding standards of course apply,
> >
> > And that's were I haven't received help so far.
>
> ... that. (Plus the GDB stuff I promised to look into.)
Well, cool, but I'd prefer that you spend your available time on the gdb
things and the *content* of the glibc patches which we need :)
(for some of the patches in mentioned in a separate mail, there is no
real explanation why they are needed, what should be done about them,
etc.)
Coding standards can be worked on by anybody, this is really something
that bug-hurd people can unload us from.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 14:33 ` Samuel Thibault
@ 2018-01-18 15:24 ` Joseph Myers
0 siblings, 0 replies; 87+ messages in thread
From: Joseph Myers @ 2018-01-18 15:24 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Florian Weimer, bug-hurd, Thomas Schwinge, GNU C Library
On Thu, 18 Jan 2018, Samuel Thibault wrote:
> Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +0000, wrote:
> > (I'd also suggest that it *not* use a top-level directory called
> > simply "libpthread" or similar without mention of Hurd, as that would
> > be too confusing to people looking at the source tree for pthreads for
> > other platforms.)
>
> Sure :)
>
> kFreeBSD/GNU used fbtl (FreeBSD Thread Library), perhaps htl? (Hurd
> Thread Library)
Seems reasonable to me.
Longer-term, once the support is in, it would be good to know how the API
exposed for pthreads on Hurd compares to the NPTL API. Right now, we have
very little documentation for threads, but in principle it would be good
to have thorough documentation for the pthreads API, and for the API to be
the same between different OSes rather than having some interfaces only
supported on some OSes. (Then most of pthread.h could be shared between
the different implementations - duplicating all the function declarations
and associated feature test macro conditionals for them is not ideal.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 15:14 ` Samuel Thibault
@ 2018-01-18 15:35 ` Joseph Myers
2018-01-18 15:42 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-01-18 15:35 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Thomas Schwinge, Florian Weimer, bug-hurd, GNU C Library
On Thu, 18 Jan 2018, Samuel Thibault wrote:
> Coding standards can be worked on by anybody, this is really something
> that bug-hurd people can unload us from.
Which is also something that having a branch with the patches is helpful
for - it allows glibc people to look over them and point out coding
standards issues to be addressed globally by people less familiar with the
conventions used in glibc. (Though when those issues are addressed the
fixes should be integrated into each patch as part of a rebase, rather
than simply adding another patch to the branch that fixes coding standards
issues with the previous patches.)
(A branch close to current master also provides a basis for anyone working
on build-many-glibcs.py support for Hurd, if you don't already have such
support among your glibc patches.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 15:35 ` Joseph Myers
@ 2018-01-18 15:42 ` Samuel Thibault
2018-01-18 16:48 ` Joseph Myers
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-01-18 15:42 UTC (permalink / raw)
To: Joseph Myers; +Cc: Thomas Schwinge, Florian Weimer, bug-hurd, GNU C Library
Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +0000, wrote:
> On Thu, 18 Jan 2018, Samuel Thibault wrote:
> > Coding standards can be worked on by anybody, this is really something
> > that bug-hurd people can unload us from.
>
> Which is also something that having a branch with the patches is helpful
> for -
Well, we already have that on
git clone git.savannah.gnu.org:/srv/git/hurd/glibc.git/
with almost a hundred branches to be looked after...
Not all of them are necessary for managing to build glibc. Some of them
are just hacking, others are perhaps almost ready to commit, just
missing changelogs & formatting. That's the triaging thing that takes
time, and having to do all the work including changelogs & formatting
makes it get lower in my global TODOlist.
That repo is not on top of master, but on top of the oldest glibc used
by the few GNU/Hurd distros. That's currently 2.24, but we have branches
to fast-forward that to 2.25 and 2.26.
> (A branch close to current master also provides a basis for anyone working
> on build-many-glibcs.py support for Hurd, if you don't already have such
> support among your glibc patches.)
That's why I suggested just committing the required patches to a branch
that we rebase regularly, so there's a master that does build.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 15:42 ` Samuel Thibault
@ 2018-01-18 16:48 ` Joseph Myers
2018-01-18 16:59 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-01-18 16:48 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Thomas Schwinge, Florian Weimer, bug-hurd, GNU C Library
On Thu, 18 Jan 2018, Samuel Thibault wrote:
> Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +0000, wrote:
> > On Thu, 18 Jan 2018, Samuel Thibault wrote:
> > > Coding standards can be worked on by anybody, this is really something
> > > that bug-hurd people can unload us from.
> >
> > Which is also something that having a branch with the patches is helpful
> > for -
>
> Well, we already have that on
>
> git clone git.savannah.gnu.org:/srv/git/hurd/glibc.git/
>
> with almost a hundred branches to be looked after...
A hundred branches with many different purposes is not something at all
convenient for glibc people to look over!
> Not all of them are necessary for managing to build glibc. Some of them
> are just hacking, others are perhaps almost ready to commit, just
> missing changelogs & formatting. That's the triaging thing that takes
> time, and having to do all the work including changelogs & formatting
> makes it get lower in my global TODOlist.
I'm still arguing on bug-standards for removing the requirement for
ChangeLog format (given a public distributed version control system), but
that wouldn't remove the requirement for proper explanations of patches,
just mean that explanations intended to be read together with the patches
themselves would suffice, without needing to duplicate the low-level
details of how the patches change each affected named entity.
> > (A branch close to current master also provides a basis for anyone working
> > on build-many-glibcs.py support for Hurd, if you don't already have such
> > support among your glibc patches.)
>
> That's why I suggested just committing the required patches to a branch
> that we rebase regularly, so there's a master that does build.
Yes, that's what I'd like to see. From the perspective of people wanting
to do global changes to glibc I think the priorities would be (a) building
cleanly for Hurd; (b) building for Hurd with the intended ABI exported
from each library at each symbol version; (c) having ABI test baselines to
verify the ABI stays as expected; (d) having all the rest of the
compilation parts of the testsuite passing. Even given just (a) I might
look at setting up build-many-glibcs.py support.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 16:48 ` Joseph Myers
@ 2018-01-18 16:59 ` Samuel Thibault
2018-01-18 23:16 ` Joseph Myers
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-01-18 16:59 UTC (permalink / raw)
To: Joseph Myers; +Cc: Thomas Schwinge, Florian Weimer, bug-hurd, GNU C Library
Joseph Myers, on jeu. 18 janv. 2018 16:47:55 +0000, wrote:
> On Thu, 18 Jan 2018, Samuel Thibault wrote:
>
> > Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +0000, wrote:
> > > On Thu, 18 Jan 2018, Samuel Thibault wrote:
> > > > Coding standards can be worked on by anybody, this is really something
> > > > that bug-hurd people can unload us from.
> > >
> > > Which is also something that having a branch with the patches is helpful
> > > for -
> >
> > Well, we already have that on
> >
> > git clone git.savannah.gnu.org:/srv/git/hurd/glibc.git/
> >
> > with almost a hundred branches to be looked after...
>
> A hundred branches with many different purposes is not something at all
> convenient for glibc people to look over!
That's why I meant work is needed to sort out what we want to show
people. Which takes triaging time, back to square 0. I sent to the
bug-hurd list the list of patches which was enough at some point to get
glibc buildable, that's what should be worked on and what I plan to
commit to a single branch on the upstream repo.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 16:59 ` Samuel Thibault
@ 2018-01-18 23:16 ` Joseph Myers
2018-01-18 23:59 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-01-18 23:16 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Thomas Schwinge, Florian Weimer, bug-hurd, GNU C Library
On Thu, 18 Jan 2018, Samuel Thibault wrote:
> That's why I meant work is needed to sort out what we want to show
> people. Which takes triaging time, back to square 0. I sent to the
> bug-hurd list the list of patches which was enough at some point to get
> glibc buildable, that's what should be worked on and what I plan to
> commit to a single branch on the upstream repo.
Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise
there will be more to get it into a buildable state, e.g. the actual
libpthread implementation).
General observations on mainly coding style issues that should be cleaned
up for actual submission (there are also obvious issues with changes to
non-Hurd-specific files needing cleaning up / justifying, which I didn't
list individually):
* Avoid __GNU__ conditionals in generic files (as per Roland's comments on
the TLS patch).
* Use <year>-2018 in copyright notices.
* There should be a descriptive comment on the first line of each file
before the copyright notice. Where you have such comments, make sure they
don't say something is a generic version when actually it's a
Hurd-specific version.
* Avoid FSF postal addresses in license notices; use a URL instead, as in
existing files in glibc (using an https URL will avoid needing to be
included in an http -> https fix for such URLs in future).
* No "Contributed by" notices in new files.
* verify.h should be LGPLv2.1+ for glibc use, but actually I think you
should just use _Static_assert instead of verify.h, since the minimum
compiler version for building glibc supports _Static_assert.
* sysdeps/mach/hurd/gai_misc.h needs a copyright / license notice (and is
missing spaces before '(' in some places).
* In a few places, missing preprocessor indentation inside #if (as per
<https://sourceware.org/glibc/wiki/Style_and_Conventions#Nested_C_Preprocessor_Directives>,
should be used except for a multiple include guard round a whole file).
* Why are some symbols added in sysdeps/mach/hurd/bits/posix_opt.h with
value 200112L, when 200809L corresponds to the POSIX version generally
supported by glibc?
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 23:16 ` Joseph Myers
@ 2018-01-18 23:59 ` Samuel Thibault
2018-01-19 0:34 ` Joseph Myers
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-01-18 23:59 UTC (permalink / raw)
To: Joseph Myers; +Cc: Thomas Schwinge, Florian Weimer, bug-hurd, GNU C Library
Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +0000, wrote:
> Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise
> there will be more to get it into a buildable state, e.g. the actual
> libpthread implementation).
What I have pushed is basically only missing the libpthread
implementation, so you already have an idea of the minimal set of
modifications to get something building (and IIRC essentially passing
the testsuite).
> General observations on mainly coding style issues that should be cleaned
> up for actual submission
Thanks for the comments!
Could bug-hurd@ help us with them? There is a lot of non-technical
stuff there :)
> * Why are some symbols added in sysdeps/mach/hurd/bits/posix_opt.h with
> value 200112L, when 200809L corresponds to the POSIX version generally
> supported by glibc?
I guess simply because at the time it wasn't the case :)
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 23:59 ` Samuel Thibault
@ 2018-01-19 0:34 ` Joseph Myers
2018-01-19 10:10 ` Thomas Schwinge
0 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-01-19 0:34 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Thomas Schwinge, Florian Weimer, bug-hurd, GNU C Library
On Fri, 19 Jan 2018, Samuel Thibault wrote:
> Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +0000, wrote:
> > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise
> > there will be more to get it into a buildable state, e.g. the actual
> > libpthread implementation).
>
> What I have pushed is basically only missing the libpthread
> implementation, so you already have an idea of the minimal set of
> modifications to get something building (and IIRC essentially passing
> the testsuite).
I'd still like to have the libpthread implementation there (with a view to
seeing if I can get build-many-glibcs.py working for Hurd with this branch
- if the branch has sources that build for Hurd, I should have some chance
of using
https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/cross-gnu?h=cross-gnu/master
to figure out how to do the Hurd-specific pieces that will need adding to
build-many-glibcs.py).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 0:34 ` Joseph Myers
@ 2018-01-19 10:10 ` Thomas Schwinge
2018-01-19 12:35 ` Manolis Ragkousis
` (2 more replies)
0 siblings, 3 replies; 87+ messages in thread
From: Thomas Schwinge @ 2018-01-19 10:10 UTC (permalink / raw)
To: Joseph Myers
Cc: Florian Weimer, GNU C Library, bug-hurd, Samuel Thibault, David Michael
Hi Joseph!
On Fri, 19 Jan 2018 00:34:42 +0000, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 19 Jan 2018, Samuel Thibault wrote:
>
> > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +0000, wrote:
> > > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise
> > > there will be more to get it into a buildable state, e.g. the actual
> > > libpthread implementation).
> >
> > What I have pushed is basically only missing the libpthread
> > implementation, so you already have an idea of the minimal set of
> > modifications to get something building (and IIRC essentially passing
> > the testsuite).
>
> I'd still like to have the libpthread implementation there (with a view to
> seeing if I can get build-many-glibcs.py working for Hurd with this branch
Many thanks for your offer! As far as I'm aware indeed nobody from the
Hurd team has spent time on that yet.
> - if the branch has sources that build for Hurd, I should have some chance
> of using
> https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/cross-gnu?h=cross-gnu/master
> to figure out how to do the Hurd-specific pieces that will need adding to
> build-many-glibcs.py).
Beware that this script is from many years ago -- from times before my
dear CodeSourcery colleagues taught be how to ;-) properly build
cross-compilers. But yes, cross-gnu did work back then.
Another thing to look into nowadays is David's (CCed) gnuxc,
<http://mid.mail-archive.com/87r3vaw4os.fsf@gmail.com> "Scripts to build
a Hurd distro", <https://github.com/dm0-/gnuxc> "GNU OS Cross-Compiler".
(I have not yet looked into that one myself.)
And, the Guix/Hurd effort also is capable of cross-compilation, as far as
I remember. But probably cross-gnu/gnuxc will already give you enough
pointers of what needs to be done.
Grüße
Thomas
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 10:10 ` Thomas Schwinge
@ 2018-01-19 12:35 ` Manolis Ragkousis
2018-01-19 13:08 ` Joseph Myers
2018-01-19 17:23 ` Joseph Myers
2 siblings, 0 replies; 87+ messages in thread
From: Manolis Ragkousis @ 2018-01-19 12:35 UTC (permalink / raw)
To: Joseph Myers
Cc: Thomas Schwinge, Florian Weimer, bug-hurd, GNU C Library,
Samuel Thibault, David Michael
Hello,
On 01/19/18 12:10, Thomas Schwinge wrote:
> Beware that this script is from many years ago -- from times before my
> dear CodeSourcery colleagues taught be how to ;-) properly build
> cross-compilers. But yes, cross-gnu did work back then.
>
> Another thing to look into nowadays is David's (CCed) gnuxc,
> <http://mid.mail-archive.com/87r3vaw4os.fsf@gmail.com> "Scripts to build
> a Hurd distro", <https://github.com/dm0-/gnuxc> "GNU OS Cross-Compiler".
> (I have not yet looked into that one myself.)
>
> And, the Guix/Hurd effort also is capable of cross-compilation, as far as
> I remember. But probably cross-gnu/gnuxc will already give you enough
> pointers of what needs to be done.
>
Guix should be able to cross-build the hurdish glibc with custom source
with `guix build --target=i586-pc-gnu glibc-hurd --with-source=glibc.tar.gz`
Manolis
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 10:10 ` Thomas Schwinge
2018-01-19 12:35 ` Manolis Ragkousis
@ 2018-01-19 13:08 ` Joseph Myers
2018-01-19 14:11 ` Thomas Schwinge
2018-01-19 17:23 ` Joseph Myers
2 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-01-19 13:08 UTC (permalink / raw)
To: Thomas Schwinge
Cc: Florian Weimer, GNU C Library, bug-hurd, Samuel Thibault, David Michael
On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> > - if the branch has sources that build for Hurd, I should have some chance
> > of using
> > https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/cross-gnu?h=cross-gnu/master
> > to figure out how to do the Hurd-specific pieces that will need adding to
> > build-many-glibcs.py).
>
> Beware that this script is from many years ago -- from times before my
> dear CodeSourcery colleagues taught be how to ;-) properly build
> cross-compilers. But yes, cross-gnu did work back then.
>
> Another thing to look into nowadays is David's (CCed) gnuxc,
> <http://mid.mail-archive.com/87r3vaw4os.fsf@gmail.com> "Scripts to build
> a Hurd distro", <https://github.com/dm0-/gnuxc> "GNU OS Cross-Compiler".
> (I have not yet looked into that one myself.)
>
> And, the Guix/Hurd effort also is capable of cross-compilation, as far as
> I remember. But probably cross-gnu/gnuxc will already give you enough
> pointers of what needs to be done.
Do you have advice on versions to use of mig / gnumach / hurd?
Currently, build-many-glibcs.py uses (by default) release versions of most
components other than glibc itself, release branches for gcc / binutils.
Should the most recent releases from ftp.gnu.org of mig / gnumach / hurd
be used for building current glibc for Hurd, or is it preferable or
necessary to use newer development versions of those components?
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 13:08 ` Joseph Myers
@ 2018-01-19 14:11 ` Thomas Schwinge
2018-01-19 15:12 ` Joseph Myers
0 siblings, 1 reply; 87+ messages in thread
From: Thomas Schwinge @ 2018-01-19 14:11 UTC (permalink / raw)
To: Joseph Myers
Cc: Florian Weimer, GNU C Library, bug-hurd, Samuel Thibault, David Michael
Hi!
On Fri, 19 Jan 2018 13:08:01 +0000, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> > > [build-many-glibcs.py]
> Do you have advice on versions to use of mig / gnumach / hurd?
>
> Currently, build-many-glibcs.py uses (by default) release versions of most
> components other than glibc itself, release branches for gcc / binutils.
> Should the most recent releases from ftp.gnu.org of mig / gnumach / hurd
> be used for building current glibc for Hurd, or is it preferable or
> necessary to use newer development versions of those components?
The current releases should generally be fine, yes.
(This reminds me that I wanted to publish new GNU Mach, MIG, Hurd,
libpthread releases, but no need for you to wait for these, as far as I
know.)
Grüße
Thomas
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 14:11 ` Thomas Schwinge
@ 2018-01-19 15:12 ` Joseph Myers
2018-01-19 18:24 ` Zack Weinberg
0 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-01-19 15:12 UTC (permalink / raw)
To: Thomas Schwinge
Cc: Florian Weimer, GNU C Library, bug-hurd, Samuel Thibault, David Michael
On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> Hi!
>
> On Fri, 19 Jan 2018 13:08:01 +0000, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> > > > [build-many-glibcs.py]
>
> > Do you have advice on versions to use of mig / gnumach / hurd?
> >
> > Currently, build-many-glibcs.py uses (by default) release versions of most
> > components other than glibc itself, release branches for gcc / binutils.
> > Should the most recent releases from ftp.gnu.org of mig / gnumach / hurd
> > be used for building current glibc for Hurd, or is it preferable or
> > necessary to use newer development versions of those components?
>
> The current releases should generally be fine, yes.
The source file sysdeps/mach/hurd/bits/errno.h is generated from sources
including some headers from those components. I don't know how often
those may change in ways that affect that header, or what versions the
current header corresponds to, but in any case it's a known issue that
there are several generated files in the source tree that
build-many-glibcs.py doesn't yet touch on checkout.
> (This reminds me that I wanted to publish new GNU Mach, MIG, Hurd,
> libpthread releases, but no need for you to wait for these, as far as I
> know.)
Regarding libpthread, I don't propose build-many-glibcs.py support for a
separate libpthread component; what's relevant is whatever version goes on
the sthibaul/hurd-builds branch of glibc (set up to build without the old
add-ons mechanism), and in due course on master.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 10:10 ` Thomas Schwinge
2018-01-19 12:35 ` Manolis Ragkousis
2018-01-19 13:08 ` Joseph Myers
@ 2018-01-19 17:23 ` Joseph Myers
2018-01-19 17:32 ` Samuel Thibault
2018-01-24 1:10 ` Samuel Thibault
2 siblings, 2 replies; 87+ messages in thread
From: Joseph Myers @ 2018-01-19 17:23 UTC (permalink / raw)
To: Thomas Schwinge
Cc: Florian Weimer, GNU C Library, bug-hurd, Samuel Thibault, David Michael
On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> Hi Joseph!
>
> On Fri, 19 Jan 2018 00:34:42 +0000, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Fri, 19 Jan 2018, Samuel Thibault wrote:
> >
> > > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +0000, wrote:
> > > > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise
> > > > there will be more to get it into a buildable state, e.g. the actual
> > > > libpthread implementation).
> > >
> > > What I have pushed is basically only missing the libpthread
> > > implementation, so you already have an idea of the minimal set of
> > > modifications to get something building (and IIRC essentially passing
> > > the testsuite).
> >
> > I'd still like to have the libpthread implementation there (with a view to
> > seeing if I can get build-many-glibcs.py working for Hurd with this branch
>
> Many thanks for your offer! As far as I'm aware indeed nobody from the
> Hurd team has spent time on that yet.
This patch adds build-many-glibcs.py support for GNU Hurd. It is
intended for master, where the builds of the i686-gnu configuration
would fail until sufficient support is merged to master, so completing
build-many-glibcs.py coverage of all glibc ABIs and making results
accurately reflect the broken state of builds for Hurd. Using
sthibaul/hurd-builds branch, it reaches the glibc build, which then
falls over with errors starting:
In file included from mutex-init.c:19:0:
../mach/lock-intern.h: In function '__spin_lock_init':
../mach/lock-intern.h:41:13: error: 'LLL_INITIALIZER' undeclared (first use in this function)
*__lock = LLL_INITIALIZER;
^~~~~~~~~~~~~~~
../mach/lock-intern.h:41:13: note: each undeclared identifier is reported only once for each function it appears in
../mach/lock-intern.h: In function '__spin_lock':
../mach/lock-intern.h:50:3: error: implicit declaration of function 'lll_lock' [-Werror=implicit-function-declaration]
lll_lock (__lock, 0);
^~~~~~~~
In file included from mutex-init.c:20:0:
../mach/lowlevellock.h: At top level:
../mach/lowlevellock.h:21:10: fatal error: mach/gnumach.h: No such file or directory
#include <mach/gnumach.h>
^~~~~~~~~~~~~~~~
Could Hurd people review how this handles building for Hurd, and
indicate whether the above errors indicate problems with these
changes, or simply incompleteness of the build support on the
sthibaul/hurd-builds branch at present?
2018-01-19 Joseph Myers <joseph@codesourcery.com>
* scripts/build-many-glibcs.py (Context.add_all_configs): Add
i686-gnu configurations.
(Context.run_builds): Include mig, gnumach and hurd in components
considered.
(Context.checkout): Add mig, gnumach and hurd to components.
(Context.checkout_tar): Add URL mappings for mig, gnumach and
hurd.
(Context.bot_cycle): Check for changes to mig, gnumach and hurd.
(Config.build): Install gnumach headers, build mig and install
hurd headers for 'gnu' OS.
(Config.install_gnumach_headers): New function.
(Config.install_hurd_headers): Likewise.
(Glibc.build_glibc): Do not use /usr for 'gnu' OS. Specifiy MIG
when building for 'gnu' OS.
diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
index 8849574..6095584 100755
--- a/scripts/build-many-glibcs.py
+++ b/scripts/build-many-glibcs.py
@@ -193,6 +193,8 @@ class Context(object):
'--with-fpu=vfpv3'])
self.add_config(arch='hppa',
os_name='linux-gnu')
+ self.add_config(arch='i686',
+ os_name='gnu')
self.add_config(arch='ia64',
os_name='linux-gnu',
first_gcc_cfg=['--with-system-libunwind'])
@@ -461,13 +463,15 @@ class Context(object):
old_versions = {}
self.build_host_libraries()
elif action == 'compilers':
- build_components = ('binutils', 'gcc', 'glibc', 'linux')
+ build_components = ('binutils', 'gcc', 'glibc', 'linux', 'mig',
+ 'gnumach', 'hurd')
old_components = ('gmp', 'mpfr', 'mpc')
old_versions = self.build_state['host-libraries']['build-versions']
self.build_compilers(configs)
else:
build_components = ('glibc',)
- old_components = ('gmp', 'mpfr', 'mpc', 'binutils', 'gcc', 'linux')
+ old_components = ('gmp', 'mpfr', 'mpc', 'binutils', 'gcc', 'linux',
+ 'mig', 'gnumach', 'hurd')
old_versions = self.build_state['compilers']['build-versions']
self.build_glibcs(configs)
self.write_files()
@@ -694,7 +698,10 @@ class Context(object):
'gmp': '6.1.2',
'linux': '4.14',
'mpc': '1.1.0',
- 'mpfr': '4.0.0'}
+ 'mpfr': '4.0.0',
+ 'mig': '1.8',
+ 'gnumach': '1.8',
+ 'hurd': '0.9'}
use_versions = {}
explicit_versions = {}
for v in versions:
@@ -829,7 +836,10 @@ class Context(object):
'gmp': 'https://ftp.gnu.org/gnu/gmp/gmp-%(version)s.tar.xz',
'linux': 'https://www.kernel.org/pub/linux/kernel/v4.x/linux-%(version)s.tar.xz',
'mpc': 'https://ftp.gnu.org/gnu/mpc/mpc-%(version)s.tar.gz',
- 'mpfr': 'https://ftp.gnu.org/gnu/mpfr/mpfr-%(version)s.tar.xz'}
+ 'mpfr': 'https://ftp.gnu.org/gnu/mpfr/mpfr-%(version)s.tar.xz',
+ 'mig': 'https://ftp.gnu.org/gnu/mig/mig-%(version)s.tar.bz2',
+ 'gnumach': 'https://ftp.gnu.org/gnu/gnumach/gnumach-%(version)s.tar.bz2',
+ 'hurd': 'https://ftp.gnu.org/gnu/hurd/hurd-%(version)s.tar.bz2'}
if component not in url_map:
print('error: component %s coming from tarball' % component)
exit(1)
@@ -949,7 +959,8 @@ class Context(object):
self.clear_last_build_state(a)
self.exec_self()
check_components = {'host-libraries': ('gmp', 'mpfr', 'mpc'),
- 'compilers': ('binutils', 'gcc', 'glibc', 'linux'),
+ 'compilers': ('binutils', 'gcc', 'glibc', 'linux',
+ 'mig', 'gnumach', 'hurd'),
'glibcs': ('glibc',)}
must_build = {}
for a in actions:
@@ -1148,6 +1159,10 @@ class Config(object):
if self.os.startswith('linux'):
self.install_linux_headers(cmdlist)
self.build_gcc(cmdlist, True)
+ if self.os == 'gnu':
+ self.install_gnumach_headers(cmdlist)
+ self.build_cross_tool(cmdlist, 'mig', 'mig')
+ self.install_hurd_headers(cmdlist)
for g in self.compiler_glibcs:
cmdlist.push_subdesc('glibc')
cmdlist.push_subdesc(g.name)
@@ -1230,6 +1245,41 @@ class Config(object):
cmdlist.cleanup_dir()
cmdlist.pop_subdesc()
+ def install_gnumach_headers(self, cmdlist):
+ """Install GNU Mach headers."""
+ srcdir = self.ctx.component_srcdir('gnumach')
+ builddir = self.component_builddir('gnumach')
+ cmdlist.push_subdesc('gnumach')
+ cmdlist.create_use_dir(builddir)
+ cmdlist.add_command('configure',
+ [os.path.join(srcdir, 'configure'),
+ '--build=%s' % self.ctx.build_triplet,
+ '--host=%s' % self.triplet,
+ '--prefix=',
+ 'CC=%s-gcc -nostdlib' % self.triplet])
+ cmdlist.add_command('install', ['make', 'DESTDIR=%s' % self.sysroot,
+ 'install-data'])
+ cmdlist.cleanup_dir()
+ cmdlist.pop_subdesc()
+
+ def install_hurd_headers(self, cmdlist):
+ """Install Hurd headers."""
+ srcdir = self.ctx.component_srcdir('hurd')
+ builddir = self.component_builddir('hurd')
+ cmdlist.push_subdesc('hurd')
+ cmdlist.create_use_dir(builddir)
+ cmdlist.add_command('configure',
+ [os.path.join(srcdir, 'configure'),
+ '--build=%s' % self.ctx.build_triplet,
+ '--host=%s' % self.triplet,
+ '--prefix=',
+ '--disable-profile', '--without-parted',
+ 'CC=%s-gcc -nostdlib' % self.triplet])
+ cmdlist.add_command('install', ['make', 'prefix=%s' % self.sysroot,
+ 'no_deps=t', 'install-headers'])
+ cmdlist.cleanup_dir()
+ cmdlist.pop_subdesc()
+
def build_gcc(self, cmdlist, bootstrap):
"""Build GCC."""
# libsanitizer commonly breaks because of glibc header
@@ -1346,8 +1396,10 @@ class Glibc(object):
# writing into the working directory. To avoid possible
# concurrency issues, copy the source directory.
cmdlist.create_copy_dir(srcdir, srcdir_copy)
+ use_usr = self.os != 'gnu'
+ prefix = '/usr' if use_usr else ''
cfg_cmd = [os.path.join(srcdir_copy, 'configure'),
- '--prefix=/usr',
+ '--prefix=%s' % prefix,
'--enable-profile',
'--build=%s' % self.ctx.build_triplet,
'--host=%s' % self.triplet,
@@ -1362,6 +1414,8 @@ class Glibc(object):
'RANLIB=%s' % self.tool_name('ranlib'),
'READELF=%s' % self.tool_name('readelf'),
'STRIP=%s' % self.tool_name('strip')]
+ if self.os == 'gnu':
+ cfg_cmd += ['MIG=%s' % self.tool_name('mig')]
cfg_cmd += self.cfg
cmdlist.add_command('configure', cfg_cmd)
cmdlist.add_command('build', ['make'])
@@ -1369,10 +1423,11 @@ class Glibc(object):
'install_root=%s' % installdir])
# GCC uses paths such as lib/../lib64, so make sure lib
# directories always exist.
- cmdlist.add_command('mkdir-lib', ['mkdir', '-p',
- os.path.join(installdir, 'lib'),
- os.path.join(installdir,
- 'usr', 'lib')])
+ mkdir_cmd = ['mkdir', '-p',
+ os.path.join(installdir, 'lib')]
+ if use_usr:
+ mkdir_cmd += [os.path.join(installdir, 'usr', 'lib')]
+ cmdlist.add_command('mkdir-lib', mkdir_cmd)
if not for_compiler:
if self.ctx.strip:
cmdlist.add_command('strip',
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 17:23 ` Joseph Myers
@ 2018-01-19 17:32 ` Samuel Thibault
2018-01-19 17:50 ` Joseph Myers
2018-01-24 1:10 ` Samuel Thibault
1 sibling, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-01-19 17:32 UTC (permalink / raw)
To: Joseph Myers
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd, David Michael
Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote:
> or simply incompleteness of the build support on the
> sthibaul/hurd-builds branch at present?
It's still incomplete, yes.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 17:32 ` Samuel Thibault
@ 2018-01-19 17:50 ` Joseph Myers
2018-01-19 17:59 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-01-19 17:50 UTC (permalink / raw)
To: Samuel Thibault
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd, David Michael
Incidentally, building for GNU/Linux (at least x86_64) is broken on the
sthibaul/hurd-builds branch (I suspect, based on the error messages, that
"t2.26/sched_param" was responsible, but didn't verify that). (I was
testing to make sure my build-many-glibcs.py changes didn't affect
GNU/Linux builds and so are safe to apply to master. Building for
GNU/Linux is not of course a priority for the branch, but any such issues
with changes to non-OS-specific code will need fixing for merging to
master.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 17:50 ` Joseph Myers
@ 2018-01-19 17:59 ` Samuel Thibault
0 siblings, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-01-19 17:59 UTC (permalink / raw)
To: Joseph Myers
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd, David Michael
Joseph Myers, on ven. 19 janv. 2018 17:50:19 +0000, wrote:
> Incidentally, building for GNU/Linux (at least x86_64) is broken on the
> sthibaul/hurd-builds branch (I suspect, based on the error messages, that
> "t2.26/sched_param" was responsible, but didn't verify that).
sched_param is very probably a culprit, yes.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 15:12 ` Joseph Myers
@ 2018-01-19 18:24 ` Zack Weinberg
2018-01-19 18:30 ` Joseph Myers
0 siblings, 1 reply; 87+ messages in thread
From: Zack Weinberg @ 2018-01-19 18:24 UTC (permalink / raw)
To: Joseph Myers
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd,
Samuel Thibault, David Michael
On Fri, Jan 19, 2018 at 10:11 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 19 Jan 2018, Thomas Schwinge wrote:
>
> The source file sysdeps/mach/hurd/bits/errno.h is generated from sources
> including some headers from those components. I don't know how often
> those may change in ways that affect that header, or what versions the
> current header corresponds to, but in any case it's a known issue that
> there are several generated files in the source tree that
> build-many-glibcs.py doesn't yet touch on checkout.
Note that there is no particularly good reason to have this file
checked in. It's generated with an awk script, and the files it's
generated from are Mach and MIG headers that I believe must be present
in order to build glibc for Hurd at all. If the Hurd build were
testable, I would probably have removed it from the source tree when I
cleaned up the errno.h __need macros, but in the current state I
didn't think it was safe.
That's the only Hurd-specific generated-but-checked-in file that I
know anything about.
zw
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 18:24 ` Zack Weinberg
@ 2018-01-19 18:30 ` Joseph Myers
0 siblings, 0 replies; 87+ messages in thread
From: Joseph Myers @ 2018-01-19 18:30 UTC (permalink / raw)
To: Zack Weinberg
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd,
Samuel Thibault, David Michael
On Fri, 19 Jan 2018, Zack Weinberg wrote:
> On Fri, Jan 19, 2018 at 10:11 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> >
> > The source file sysdeps/mach/hurd/bits/errno.h is generated from sources
> > including some headers from those components. I don't know how often
> > those may change in ways that affect that header, or what versions the
> > current header corresponds to, but in any case it's a known issue that
> > there are several generated files in the source tree that
> > build-many-glibcs.py doesn't yet touch on checkout.
>
> Note that there is no particularly good reason to have this file
> checked in. It's generated with an awk script, and the files it's
I'm not sure if having a non-checked-in generated file override another
file in the source tree works correctly, the way a checked-in sysdeps file
does override other files in the source tree. (sysdeps/gnu/errlist.c is
another case of a sysdeps generated file - it needs to override
stdio-common/errlist.c, and for that matter gets included by
sysdeps/mach/hurd/errlist.c.)
If the search orderings work correctly - both for finding files during the
build, and for installing the correct bits/errno.h header (and the
build-tree errlist.c can be properly included from the source-tree
sysdeps/mach/hurd/errlist.c) - then there shouldn't be any need for either
sysdeps/mach/hurd/bits/errno.h or sysdeps/gnu/errlist.c to be checked in.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-19 17:23 ` Joseph Myers
2018-01-19 17:32 ` Samuel Thibault
@ 2018-01-24 1:10 ` Samuel Thibault
2018-01-24 1:26 ` Joseph Myers
2018-01-24 1:27 ` Samuel Thibault
1 sibling, 2 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-01-24 1:10 UTC (permalink / raw)
To: Joseph Myers
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd, David Michael
Hello,
Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote:
> Could Hurd people review how this handles building for Hurd,
Yes, it looks good.
> and indicate whether the above errors indicate problems with these
> changes, or simply incompleteness of the build support on the
> sthibaul/hurd-builds branch at present?
They are not related to the changes. I have pushed fix updates against
them.
There is just one missing thing: mig prototypes etc. are not perfect,
and we thus have some nasty warnings about void * vs const void *. We'd
have to use
if self.os == 'gnu':
cfg_cmd += ['MIG=%s' % self.tool_name('mig')]
+ cfg_cmd += ['--disable-werror']
for now until we fix that.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-24 1:10 ` Samuel Thibault
@ 2018-01-24 1:26 ` Joseph Myers
2018-01-24 1:27 ` Samuel Thibault
1 sibling, 0 replies; 87+ messages in thread
From: Joseph Myers @ 2018-01-24 1:26 UTC (permalink / raw)
To: Samuel Thibault
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd, David Michael
On Wed, 24 Jan 2018, Samuel Thibault wrote:
> Hello,
>
> Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote:
> > Could Hurd people review how this handles building for Hurd,
>
> Yes, it looks good.
Thanks, I've committed it to master.
> > and indicate whether the above errors indicate problems with these
> > changes, or simply incompleteness of the build support on the
> > sthibaul/hurd-builds branch at present?
>
> They are not related to the changes. I have pushed fix updates against
> them.
Now I see errors about missing libc-lockP.h, and "implicit declaration of
function '__spin_lock_solid'", and the discarded qualifiers errors you
note below.
> There is just one missing thing: mig prototypes etc. are not perfect,
> and we thus have some nasty warnings about void * vs const void *. We'd
> have to use
>
> if self.os == 'gnu':
> cfg_cmd += ['MIG=%s' % self.tool_name('mig')]
> + cfg_cmd += ['--disable-werror']
>
> for now until we fix that.
A properly upstreamed port should not need --disable-werror. If
workarounds are needed until there's a fixed mig release (or whatever),
they could take the form of explicit casts, or CFLAGS-<file> +=
-Wno-error=discarded-qualifiers - disabling a particular warning being an
error in a particular file is much better than globally disabling all
warnings as errors. (Strictly -Wno-error=discarded-qualifiers shouldn't
be used unconditionally since that warning option is new in GCC 5 and
glibc supports building with GCC 4.9, but in the current state of the Hurd
port I think we can ignore that in Hurd-specific Makefiles.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-24 1:10 ` Samuel Thibault
2018-01-24 1:26 ` Joseph Myers
@ 2018-01-24 1:27 ` Samuel Thibault
2018-01-25 1:41 ` Samuel Thibault
1 sibling, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-01-24 1:27 UTC (permalink / raw)
To: Joseph Myers, Thomas Schwinge, Florian Weimer, GNU C Library,
bug-hurd, David Michael
Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote:
> Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote:
> > and indicate whether the above errors indicate problems with these
> > changes, or simply incompleteness of the build support on the
> > sthibaul/hurd-builds branch at present?
>
> They are not related to the changes. I have pushed fix updates against
> them.
The next error is about inclusion of libc-lockP.h. That's where I'll
have to import libpthread.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-24 1:27 ` Samuel Thibault
@ 2018-01-25 1:41 ` Samuel Thibault
2018-01-25 15:43 ` Joseph Myers
2018-01-25 16:12 ` Joseph Myers
0 siblings, 2 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-01-25 1:41 UTC (permalink / raw)
To: Joseph Myers, Thomas Schwinge, Florian Weimer, GNU C Library,
bug-hurd, David Michael
Samuel Thibault, on mer. 24 janv. 2018 02:27:26 +0100, wrote:
> Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote:
> > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote:
> > > and indicate whether the above errors indicate problems with these
> > > changes, or simply incompleteness of the build support on the
> > > sthibaul/hurd-builds branch at present?
> >
> > They are not related to the changes. I have pushed fix updates against
> > them.
>
> The next error is about inclusion of libc-lockP.h. That's where I'll
> have to import libpthread.
Which I have now done. I see that it now fails on missing reference to
__file_exec_paths. That's indeed a new RPC which hasn't been released
yet, so we'd need to use a git snapshot.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-25 1:41 ` Samuel Thibault
@ 2018-01-25 15:43 ` Joseph Myers
2018-01-25 16:12 ` Joseph Myers
1 sibling, 0 replies; 87+ messages in thread
From: Joseph Myers @ 2018-01-25 15:43 UTC (permalink / raw)
To: Samuel Thibault
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd, David Michael
On Thu, 25 Jan 2018, Samuel Thibault wrote:
> Samuel Thibault, on mer. 24 janv. 2018 02:27:26 +0100, wrote:
> > Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote:
> > > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote:
> > > > and indicate whether the above errors indicate problems with these
> > > > changes, or simply incompleteness of the build support on the
> > > > sthibaul/hurd-builds branch at present?
> > >
> > > They are not related to the changes. I have pushed fix updates against
> > > them.
> >
> > The next error is about inclusion of libc-lockP.h. That's where I'll
> > have to import libpthread.
>
> Which I have now done. I see that it now fails on missing reference to
> __file_exec_paths. That's indeed a new RPC which hasn't been released
> yet, so we'd need to use a git snapshot.
If a git version of Hurd (or some other component) is needed, it would be
reasonable to make vcs-mainline the default version of Hurd until there's
a new release. Longer-term (once Hurd is working on master) I'd hope
there would be a clear (and documented) notion of minimum compile-time and
run-time Hurd versions, as there is for glibc using the Linux kernel, with
any features of newer versions being used only conditionally, so that the
most recent releases are generally sufficient to build and use glibc for
Hurd.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-25 1:41 ` Samuel Thibault
2018-01-25 15:43 ` Joseph Myers
@ 2018-01-25 16:12 ` Joseph Myers
2018-01-25 16:20 ` Samuel Thibault
2018-03-19 1:51 ` Samuel Thibault
1 sibling, 2 replies; 87+ messages in thread
From: Joseph Myers @ 2018-01-25 16:12 UTC (permalink / raw)
To: Samuel Thibault
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd, David Michael
Regarding the libpthread / htl code, and getting it ready for inclusion in
glibc master:
Obviously my general coding style comments at
<https://sourceware.org/ml/libc-alpha/2018-01/msg00646.html> apply equally
to this code. Apart from that:
* Remove htl/ChangeLog. We don't have subdirectory ChangeLogs now.
Everything goes in the top-level ChangeLog, with older ChangeLogs (that
have actual ChangeLog content) being in the ChangeLog.old/ directory.
When importing files / patches previously maintained elsewhere, I *do*
think the ChangeLog header for those patches should name all authors who
contributed to them (which may make for a long header with lots of authors
listed). (If the GNU Coding Standards change to stop requiring ChangeLog
format and we decide to stop using it, we'll still need some convention
for how to credit multi-author patches.)
* Remove htl/tests/.cvsignore.
* Support for building htl outside the glibc source tree (or with older
glibc versions) should not be included.
* Files in htl/sysdeps should be moved into appropriate locations in the
main sysdeps tree, just as was done with nptl/sysdeps when nptl ceased to
be an add-on.
* You seem to have some custom system for building tests in htl/tests.
Tests should be built and run using the normal glibc testsuite machinery
(and should use <support/test-driver.c>).
* You have four installed non-bits/ API headers: pthread.h
pthread/pthread.h pthread/pthreadtypes.h semaphore.h. NPTL has just
pthread.h and semaphore.h. Do you really need pthread/pthread.h and
pthread/pthreadtypes.h as installed public API headers? I'd expect the
same two API headers as NPTL has.
* The bits/ convention is for headers that are (a) installed, (b) only for
use by other installed headers, not for direct inclusion by users (and
sometimes have #error conditionals to guard against direct inclusion).
Within that convention, there's a newer bits/types/ convention for headers
defining a single type, which is intended as a replacement for the older
__need_* convention. Now, this brings up three points regarding the htl
code (and possibly other pieces in the Hurd port).
(i) You still have some headers that define or use __need_*; those should
be changed to use bits/types/ headers (__need_* has generally been
eliminated from glibc, except where it's defined before including *GCC*
headers, not glibc ones).
(ii) Some of the bits/ headers in htl look like they are just defining a
single type, so should actually be bits/types/ headers named according to
the new convention.
(iii) bits/memory.h and bits/pt-atomic.h don't appear to be installed
headers, meaning they should not have bits/ names. Actually, uses of
those headers should probably be changed to use glibc's existing atomic.h
interfaces, and those htl-specific headers removed - if for some reason
the existing atomic.h interfaces are insufficient, maybe those interfaces
need to be extended.
The following would be desirable cleanups, but maybe for after the code is
in master:
* I'd expect that NPTL tests (and likewise HTL tests) are largely tests of
POSIX (or GNU extension) threading functionality, not of features specific
to one threading implementation. Thus, they should as far as possible be
shared between the different threading implementations. I don't know the
best directory arrangements for achieving that.
* Hopefully C11 threads support will be added for 2.28 (didn't get
reviewed in time for 2.27). The existing patches put it in the nptl/
directory, but again, to the extent that it actually builds on generic
pthreads functionality, the code and its tests should be shared as much as
possible between NPTL and HTL.
* Likewise for the pthread.h and semaphore.h API headers - only parts
genuinely specific to a given implementation should be split out into
implementation-specific bits/ headers. (Indeed, the NPTL semaphore.h is
already in sysdeps/pthread/ not an NPTL-specific directory - do you really
need a different one for HTL?)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-25 16:12 ` Joseph Myers
@ 2018-01-25 16:20 ` Samuel Thibault
2018-03-19 1:51 ` Samuel Thibault
1 sibling, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-01-25 16:20 UTC (permalink / raw)
To: Joseph Myers
Cc: Thomas Schwinge, Florian Weimer, GNU C Library, bug-hurd, David Michael
Joseph Myers, on jeu. 25 janv. 2018 16:12:48 +0000, wrote:
> do you really need [foo]
Assume no :)
I just imported the source as it is, containing everything that was
previously needed to make it buildable both within the hurd repository
and the glibc repository.
Thanks for listing the issues, though :)
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-18 14:03 ` Joseph Myers
@ 2018-01-28 18:40 ` Samuel Thibault
0 siblings, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-01-28 18:40 UTC (permalink / raw)
To: Joseph Myers; +Cc: Florian Weimer, bug-hurd, Thomas Schwinge, GNU C Library
Hello,
Joseph Myers, on jeu. 18 janv. 2018 14:03:18 +0000, wrote:
> On Thu, 18 Jan 2018, Samuel Thibault wrote:
>
> > > Before Hurd support is fully integrated in glibc, I'd encourage having a
> > > branch *in the glibc repository* that contains such support, so we can
> > > more readily see what the changes yet to be merged are (and possibly
> > > comment on issues that will need addressing when integrating them in
> > > glibc).
> >
> > I can pile-commit what we currently have, with all the XXXs, FIXMEs,
> > etc., if that can help the glibc side.
>
> I think having such a branch [...] would be helpful so we can see
> the changes and quite likely point out global issues to be addressed
> throughout.
The branch now does build fine :)
The next issue is that some tests fail to build.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-01-25 16:12 ` Joseph Myers
2018-01-25 16:20 ` Samuel Thibault
@ 2018-03-19 1:51 ` Samuel Thibault
2018-03-19 15:36 ` Zack Weinberg
` (2 more replies)
1 sibling, 3 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-03-19 1:51 UTC (permalink / raw)
To: Joseph Myers, Florian Weimer
Cc: Thomas Schwinge, GNU C Library, bug-hurd, David Michael
Hello,
Thanks a lot for the feedback on what needs to be done. It was a busy
week-end :)
We should be almost there, I believe I had addressed in
sthibaul/hurd-builds all requirements except a few remaining bits:
- Two patches pending comments on libc-alpha:
[PATCH] hurd: Initialize TLS and libpthread before signal thread start
[PATCH] hurd: Fix early rtld access to errno
- plugging the htl tests to the glibc test infrastructure.
- Fixing GNU Coding Style, notably first line of files.
- Fixing the date in sysdeps/mach/hurd/bits/posix_opt.h.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-19 1:51 ` Samuel Thibault
@ 2018-03-19 15:36 ` Zack Weinberg
2018-03-19 15:47 ` Samuel Thibault
2018-03-26 23:13 ` Rafal Luzynski
2018-04-02 0:10 ` Samuel Thibault
2 siblings, 1 reply; 87+ messages in thread
From: Zack Weinberg @ 2018-03-19 15:36 UTC (permalink / raw)
To: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> Hello,
>
> Thanks a lot for the feedback on what needs to be done. It was a busy
> week-end :)
>
> We should be almost there, I believe I had addressed in
> sthibaul/hurd-builds all requirements except a few remaining bits:
Is it still expected that glibc trunk cannot be built in the
--host=i686-gnu configuration? I am getting
In file included from ../include/link.h:52:0,
from ../include/dlfcn.h:4,
from ../sysdeps/generic/ldsodefs.h:32,
from ../sysdeps/i386/ldsodefs.h:39,
from ../sysdeps/gnu/ldsodefs.h:46,
from setup-thread.c:22:
../sysdeps/mach/libc-lock.h:227:11: fatal error: libc-lockP.h: No such
file or directory
# include <libc-lockP.h>
^~~~~~~~~~~~~~
compilation terminated.
(I would like to suggest that getting "scripts/build-many-glibcs.py
$workdir compilers i686-gnu" to succeed, and
"scripts/build-many-glibcs.py $workdir glibcs i686-gnu" to fail only
in the testsuite phase, when $workdir/src/glibc contains a trunk
checkout, should be top priority -- once you get to that point, people
working on cross-cutting changes (like me) can ensure that they
haven't made the state of the Hurd port worse.)
zw
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-19 15:36 ` Zack Weinberg
@ 2018-03-19 15:47 ` Samuel Thibault
2018-03-19 15:54 ` Zack Weinberg
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-03-19 15:47 UTC (permalink / raw)
To: Zack Weinberg
Cc: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
Zack Weinberg, on lun. 19 mars 2018 11:36:18 -0400, wrote:
> On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault
> <samuel.thibault@gnu.org> wrote:
> > Hello,
> >
> > Thanks a lot for the feedback on what needs to be done. It was a busy
> > week-end :)
> >
> > We should be almost there, I believe I had addressed in
> > sthibaul/hurd-builds all requirements except a few remaining bits:
>
> Is it still expected that glibc trunk cannot be built in the
> --host=i686-gnu configuration? I am getting
Are you using the sthibaul/hurd-builds branch?
There are still things missing in master, notably the htl/
directories.
> (I would like to suggest that getting "scripts/build-many-glibcs.py
> $workdir compilers i686-gnu" to succeed,
It does work on my system with the sthibaul/hurd-builds branch.
> when $workdir/src/glibc contains a trunk checkout, should be top
> priority
Sure, that's precisely my goal. I'm just checking for things that might
look odd in the sthibaul/hurd-builds branch before I push them to
master.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-19 15:47 ` Samuel Thibault
@ 2018-03-19 15:54 ` Zack Weinberg
2018-03-19 16:05 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Zack Weinberg @ 2018-03-19 15:54 UTC (permalink / raw)
To: Zack Weinberg, Joseph Myers, Florian Weimer, Thomas Schwinge,
GNU C Library, bug-hurd, David Michael
On Mon, Mar 19, 2018 at 11:46 AM, Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> Zack Weinberg, on lun. 19 mars 2018 11:36:18 -0400, wrote:
>> On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault
>> <samuel.thibault@gnu.org> wrote:
>> > Hello,
>> >
>> > Thanks a lot for the feedback on what needs to be done. It was a busy
>> > week-end :)
>> >
>> > We should be almost there, I believe I had addressed in
>> > sthibaul/hurd-builds all requirements except a few remaining bits:
>>
>> Is it still expected that glibc trunk cannot be built in the
>> --host=i686-gnu configuration? I am getting
>
> Are you using the sthibaul/hurd-builds branch?
No, that's what I meant by "glibc trunk".
> There are still things missing in master, notably the htl/
> directories.
Oh, OK. No hurry.
zw
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-19 15:54 ` Zack Weinberg
@ 2018-03-19 16:05 ` Samuel Thibault
0 siblings, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-03-19 16:05 UTC (permalink / raw)
To: Zack Weinberg
Cc: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
Zack Weinberg, on lun. 19 mars 2018 11:54:21 -0400, wrote:
> On Mon, Mar 19, 2018 at 11:46 AM, Samuel Thibault
> <samuel.thibault@gnu.org> wrote:
> > Zack Weinberg, on lun. 19 mars 2018 11:36:18 -0400, wrote:
> >> On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault
> >> <samuel.thibault@gnu.org> wrote:
> >> > Hello,
> >> >
> >> > Thanks a lot for the feedback on what needs to be done. It was a busy
> >> > week-end :)
> >> >
> >> > We should be almost there, I believe I had addressed in
> >> > sthibaul/hurd-builds all requirements except a few remaining bits:
> >>
> >> Is it still expected that glibc trunk cannot be built in the
> >> --host=i686-gnu configuration? I am getting
> >
> > Are you using the sthibaul/hurd-builds branch?
>
> No, that's what I meant by "glibc trunk".
Ok, sorry, I missed the "trunk" workd :)
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-19 1:51 ` Samuel Thibault
2018-03-19 15:36 ` Zack Weinberg
@ 2018-03-26 23:13 ` Rafal Luzynski
2018-03-27 7:45 ` Samuel Thibault
2018-03-27 9:01 ` Samuel Thibault
2018-04-02 0:10 ` Samuel Thibault
2 siblings, 2 replies; 87+ messages in thread
From: Rafal Luzynski @ 2018-03-26 23:13 UTC (permalink / raw)
To: Samuel Thibault; +Cc: GNU C Library, bug-hurd
Hello Samuel,
19.03.2018 02:51 Samuel Thibault <samuel.thibault@gnu.org> wrote:
>
> Hello,
>
> Thanks a lot for the feedback on what needs to be done. It was a busy
> week-end :)
I appreciate your work. :-) Sorry for a kinda off-topic but could you
please visit the Patchwork site [1] and mark your committed patches
as committed, or ask someone to do it for you? I'm asking in public
because there are lots of patches from other people as well, also this
makes a chance for someone to respond in case if I'm too overzealous.
Thank you.
Regards,
Rafal
[1] https://patchwork.sourceware.org/project/glibc/list/
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-26 23:13 ` Rafal Luzynski
@ 2018-03-27 7:45 ` Samuel Thibault
2018-03-27 9:01 ` Samuel Thibault
1 sibling, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-03-27 7:45 UTC (permalink / raw)
To: Rafal Luzynski; +Cc: GNU C Library, bug-hurd
Hello,
Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote:
> I appreciate your work. :-) Sorry for a kinda off-topic but could you
> please visit the Patchwork site [1] and mark your committed patches
> as committed, or ask someone to do it for you?
Oh, I didn't know about it. Is there a way to make them marked as
commited right from the mail subject, for future commits?
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-26 23:13 ` Rafal Luzynski
2018-03-27 7:45 ` Samuel Thibault
@ 2018-03-27 9:01 ` Samuel Thibault
2018-03-27 10:40 ` Rafal Luzynski
2018-03-27 14:46 ` Tulio Magno Quites Machado Filho
1 sibling, 2 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-03-27 9:01 UTC (permalink / raw)
To: Rafal Luzynski; +Cc: GNU C Library, bug-hurd
Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote:
> 19.03.2018 02:51 Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > Thanks a lot for the feedback on what needs to be done. It was a busy
> > week-end :)
>
> I appreciate your work. :-) Sorry for a kinda off-topic but could you
> please visit the Patchwork site [1] and mark your committed patches
> as committed, or ask someone to do it for you?
It seems I can't mark patches submitted by other people, perhaps I just
need to be added to the "Maintainers" list?
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-27 9:01 ` Samuel Thibault
@ 2018-03-27 10:40 ` Rafal Luzynski
2018-03-27 10:43 ` Samuel Thibault
2018-03-27 14:46 ` Tulio Magno Quites Machado Filho
1 sibling, 1 reply; 87+ messages in thread
From: Rafal Luzynski @ 2018-03-27 10:40 UTC (permalink / raw)
To: Samuel Thibault; +Cc: GNU C Library, bug-hurd
27.03.2018 09:45 Samuel Thibault <samuel.thibault@gnu.org> wrote:
> [...]
> Oh, I didn't know about it. Is there a way to make them marked as
> commited right from the mail subject, for future commits?
I don't know. Any hints, anybody?
27.03.2018 11:00 Samuel Thibault <samuel.thibault@gnu.org> wrote:
> [...]
> It seems I can't mark patches submitted by other people, perhaps I just
> need to be added to the "Maintainers" list?
No, I wouldn't ask you to mark patches by other people, if you mark
your own patches that would be a great cleaning work already.
When I mentioned other people I meant that other people should
do the same with their own patches, so that's a general message,
not just for you.
Regards,
Rafal
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-27 10:40 ` Rafal Luzynski
@ 2018-03-27 10:43 ` Samuel Thibault
2018-03-27 10:53 ` Rafal Luzynski
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-03-27 10:43 UTC (permalink / raw)
To: Rafal Luzynski; +Cc: GNU C Library, bug-hurd
Rafal Luzynski, on mar. 27 mars 2018 12:40:27 +0200, wrote:
> 27.03.2018 11:00 Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > [...]
> > It seems I can't mark patches submitted by other people, perhaps I just
> > need to be added to the "Maintainers" list?
>
> No, I wouldn't ask you to mark patches by other people, if you mark
> your own patches that would be a great cleaning work already.
Just to be sure: I meant patches submitted by others which I have
commited myself to glibc.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-27 10:43 ` Samuel Thibault
@ 2018-03-27 10:53 ` Rafal Luzynski
0 siblings, 0 replies; 87+ messages in thread
From: Rafal Luzynski @ 2018-03-27 10:53 UTC (permalink / raw)
To: Samuel Thibault; +Cc: GNU C Library, bug-hurd
27.03.2018 12:43 Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Rafal Luzynski, on mar. 27 mars 2018 12:40:27 +0200, wrote:
> > 27.03.2018 11:00 Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > > [...]
> > > It seems I can't mark patches submitted by other people, perhaps I just
> > > need to be added to the "Maintainers" list?
> >
> > No, I wouldn't ask you to mark patches by other people, if you mark
> > your own patches that would be a great cleaning work already.
>
> Just to be sure: I meant patches submitted by others which I have
> commited myself to glibc.
That's only more confusing for me. I am a relatively new maintainer
here, this explains why it is so easy for me to put my attention on
the things I learned not so long ago. Regarding your questions we need
some feedback from more experienced maintainers, I am curious as well.
Regards,
Rafal
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-27 9:01 ` Samuel Thibault
2018-03-27 10:40 ` Rafal Luzynski
@ 2018-03-27 14:46 ` Tulio Magno Quites Machado Filho
2018-03-27 14:53 ` Carlos O'Donell
2018-03-27 16:31 ` Samuel Thibault
1 sibling, 2 replies; 87+ messages in thread
From: Tulio Magno Quites Machado Filho @ 2018-03-27 14:46 UTC (permalink / raw)
To: Samuel Thibault, Rafal Luzynski
Cc: GNU C Library, bug-hurd, Carlos O'Donell, Siddhesh Poyarekar
Samuel Thibault <samuel.thibault@gnu.org> writes:
> Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote:
>> 19.03.2018 02:51 Samuel Thibault <samuel.thibault@gnu.org> wrote:
>> > Thanks a lot for the feedback on what needs to be done. It was a busy
>> > week-end :)
>>
>> I appreciate your work. :-) Sorry for a kinda off-topic but could you
>> please visit the Patchwork site [1] and mark your committed patches
>> as committed, or ask someone to do it for you?
>
> It seems I can't mark patches submitted by other people, perhaps I just
> need to be added to the "Maintainers" list?
Indeed.
Carlos and Siddhesh, could you help Samuel?
For the record: Carlos and Siddhesh are the maintainers of our Patchwork
instance.
https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_the_patchwork_instance
I can't put your account in the maintainers list, but I can change the status
of the patches.
Are these all the patches pending an update there?
https://patchwork.sourceware.org/project/glibc/list/?submitter=384
--
Tulio Magno
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-27 14:46 ` Tulio Magno Quites Machado Filho
@ 2018-03-27 14:53 ` Carlos O'Donell
2018-03-27 16:31 ` Samuel Thibault
1 sibling, 0 replies; 87+ messages in thread
From: Carlos O'Donell @ 2018-03-27 14:53 UTC (permalink / raw)
To: Tulio Magno Quites Machado Filho, Samuel Thibault, Rafal Luzynski
Cc: GNU C Library, bug-hurd, Siddhesh Poyarekar
On 03/27/2018 09:46 AM, Tulio Magno Quites Machado Filho wrote:
> Samuel Thibault <samuel.thibault@gnu.org> writes:
>
>> Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote:
>>> 19.03.2018 02:51 Samuel Thibault <samuel.thibault@gnu.org> wrote:
>>>> Thanks a lot for the feedback on what needs to be done. It was a busy
>>>> week-end :)
>>>
>>> I appreciate your work. :-) Sorry for a kinda off-topic but could you
>>> please visit the Patchwork site [1] and mark your committed patches
>>> as committed, or ask someone to do it for you?
>>
>> It seems I can't mark patches submitted by other people, perhaps I just
>> need to be added to the "Maintainers" list?
>
> Indeed.
>
> Carlos and Siddhesh, could you help Samuel?
Fixed. I added Samuel to the maintainers list.
> For the record: Carlos and Siddhesh are the maintainers of our Patchwork
> instance.
> https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_the_patchwork_instance
>
> I can't put your account in the maintainers list, but I can change the status
> of the patches.
> Are these all the patches pending an update there?
> https://patchwork.sourceware.org/project/glibc/list/?submitter=384
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-27 14:46 ` Tulio Magno Quites Machado Filho
2018-03-27 14:53 ` Carlos O'Donell
@ 2018-03-27 16:31 ` Samuel Thibault
1 sibling, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-03-27 16:31 UTC (permalink / raw)
To: Tulio Magno Quites Machado Filho, Carlos O'Donell
Cc: Rafal Luzynski, GNU C Library, bug-hurd, Siddhesh Poyarekar
Tulio Magno Quites Machado Filho, on mar. 27 mars 2018 11:46:32 -0300, wrote:
> Are these all the patches pending an update there?
> https://patchwork.sourceware.org/project/glibc/list/?submitter=384
No, it's not all of them, so it's really me who should work it out :)
Carlos O'Donell, on mar. 27 mars 2018 09:52:54 -0500, wrote:
> On 03/27/2018 09:46 AM, Tulio Magno Quites Machado Filho wrote:
> > Samuel Thibault <samuel.thibault@gnu.org> writes:
> >
> >> Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote:
> >>> 19.03.2018 02:51 Samuel Thibault <samuel.thibault@gnu.org> wrote:
> >>>> Thanks a lot for the feedback on what needs to be done. It was a busy
> >>>> week-end :)
> >>>
> >>> I appreciate your work. :-) Sorry for a kinda off-topic but could you
> >>> please visit the Patchwork site [1] and mark your committed patches
> >>> as committed, or ask someone to do it for you?
> >>
> >> It seems I can't mark patches submitted by other people, perhaps I just
> >> need to be added to the "Maintainers" list?
> >
> > Indeed.
> >
> > Carlos and Siddhesh, could you help Samuel?
>
> Fixed. I added Samuel to the maintainers list.
Thanks! It works indeed.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-03-19 1:51 ` Samuel Thibault
2018-03-19 15:36 ` Zack Weinberg
2018-03-26 23:13 ` Rafal Luzynski
@ 2018-04-02 0:10 ` Samuel Thibault
2018-04-02 7:51 ` Florian Weimer
` (3 more replies)
2 siblings, 4 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-04-02 0:10 UTC (permalink / raw)
To: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
Hello,
So, after various coding style fixes etc. I eventually pushed htl.
This means that build-glibcs i686-gnu now builds fine. Among the
remaining TODOs, there are
- making testsuite pass
- fixing the generated errno file thing
- sharing tests between nptl and htl
- sharing pthread.h
- C11 threads
Concerning the testsuite, perhaps we could xfail the existing issues so
that build-glibcs i686-gnu succeeds?
Currently there are:
- header standard conformity issues: These will be hard to fix.
- elf/check-localplt: There will always be PLTs to libhurd/machuser.so
anyway.
- elf/check-execstack: We have nested functions which make the stack
executable indeed.
- check-abi-libmachuser, check-abi-libhurduser: These actually depend on
.defs files in gnumach and hurd, so we can't really define ABI files.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 0:10 ` Samuel Thibault
@ 2018-04-02 7:51 ` Florian Weimer
2018-04-02 8:24 ` Samuel Thibault
2018-04-02 14:17 ` Joseph Myers
` (2 subsequent siblings)
3 siblings, 1 reply; 87+ messages in thread
From: Florian Weimer @ 2018-04-02 7:51 UTC (permalink / raw)
To: Joseph Myers, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On 04/02/2018 02:10 AM, Samuel Thibault wrote:
> - elf/check-execstack: We have nested functions which make the stack
> executable indeed.
I looked at the Hurd situation last month. Hurd is always
read-implies-exec, I think. So there is no need to make the stacks
executable, it does not have any observable effect on execution and
therefore cannot be tested.
Thanks,
Florian
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 7:51 ` Florian Weimer
@ 2018-04-02 8:24 ` Samuel Thibault
0 siblings, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-04-02 8:24 UTC (permalink / raw)
To: Florian Weimer
Cc: Joseph Myers, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
Florian Weimer, on lun. 02 avril 2018 09:51:00 +0200, wrote:
> On 04/02/2018 02:10 AM, Samuel Thibault wrote:
> > - elf/check-execstack: We have nested functions which make the stack
> > executable indeed.
>
> I looked at the Hurd situation last month. Hurd is always
> read-implies-exec, I think.
Nobody has implemented NX in gnumach yet, but that doesn't mean nobody
will.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 0:10 ` Samuel Thibault
2018-04-02 7:51 ` Florian Weimer
@ 2018-04-02 14:17 ` Joseph Myers
2018-04-02 15:50 ` Samuel Thibault
2018-04-02 14:22 ` Joseph Myers
2018-04-03 15:45 ` Joseph Myers
3 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-04-02 14:17 UTC (permalink / raw)
To: Samuel Thibault
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On Mon, 2 Apr 2018, Samuel Thibault wrote:
> - header standard conformity issues: These will be hard to fix.
What are the issues here?
> - elf/check-localplt: There will always be PLTs to libhurd/machuser.so
> anyway.
If a library has *local* PLT entries - PLT entries for within-library
calls to other functions in that shared library - that are hard to fix to
use hidden aliases, it's expected that the localplt.data files will list
those as expected (with a "?" if the PLT entry may or may not be present
depending on compiler version etc., as is the case for some configurations
where functions get exported from both libgcc and glibc).
> - elf/check-execstack: We have nested functions which make the stack
> executable indeed.
That's pointers to nested functions involving creation of trampolines?
Do those nested functions actually improve the code or would it be cleaner
(have cleaner internal interfaces etc.) without them? Do all libraries
have these or only some?
> - check-abi-libmachuser, check-abi-libhurduser: These actually depend on
> .defs files in gnumach and hurd, so we can't really define ABI files.
Depend in what way? Are you saying they export different symbols
depending on the versions of gnumach and hurd glibc is built with? How
are symbol versions for such extra symbols determined - based on gnumach
and hurd versions instead of glibc versions?
It's clearly desirable to be able to make sure that old symbol versions
don't change. But if the contents of those versions are determined by
gnumach and hurd, maybe those packages need to install ABI baselines for
the glibc tests (or something like that).
The nearest analogue I see in glibc for systems using the Linux kernel
(without more information on how the gnumach/hurd dependency works) is the
syscall lists - where we have a list in glibc of all possible syscall
names (sysdeps/unix/sysv/linux/syscall-names.list), and a test will fail
if the kernel has additional syscalls and is not newer than the version
listed in that list (so using a different kernel version does not result
in test failures, but the test is fully effective if the listed kernel
version or an older kernel version is used).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 0:10 ` Samuel Thibault
2018-04-02 7:51 ` Florian Weimer
2018-04-02 14:17 ` Joseph Myers
@ 2018-04-02 14:22 ` Joseph Myers
2018-04-02 14:47 ` Samuel Thibault
2018-04-03 15:45 ` Joseph Myers
3 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-04-02 14:22 UTC (permalink / raw)
To: Samuel Thibault
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On Mon, 2 Apr 2018, Samuel Thibault wrote:
> This means that build-glibcs i686-gnu now builds fine. Among the
> remaining TODOs, there are
Thanks! I'd add: the "requires out-of-tree patches" statement in README
needs to be removed, and a NEWS entry is needed. Will you be able to
provide full execution test results for the testsuite on the per-release
wiki pages for 2.28 and later releases, during each release freeze period?
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 14:22 ` Joseph Myers
@ 2018-04-02 14:47 ` Samuel Thibault
2018-04-02 16:01 ` H.J. Lu
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-04-02 14:47 UTC (permalink / raw)
To: Joseph Myers
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
Hello,
Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote:
> On Mon, 2 Apr 2018, Samuel Thibault wrote:
>
> > This means that build-glibcs i686-gnu now builds fine. Among the
> > remaining TODOs, there are
>
> Thanks! I'd add: the "requires out-of-tree patches" statement in README
> needs to be removed,
Oh, I was unaware of that mention.
> and a NEWS entry is needed.
Right :)
> Will you be able to provide full execution test results for the
> testsuite on the per-release wiki pages for 2.28 and later releases,
> during each release freeze period?
Now that it does build and run quite fine, sure! :)
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 14:17 ` Joseph Myers
@ 2018-04-02 15:50 ` Samuel Thibault
2018-04-02 16:13 ` Samuel Thibault
2018-04-03 0:10 ` Joseph Myers
0 siblings, 2 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-04-02 15:50 UTC (permalink / raw)
To: Joseph Myers
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
Joseph Myers, on lun. 02 avril 2018 14:17:38 +0000, wrote:
> On Mon, 2 Apr 2018, Samuel Thibault wrote:
>
> > - header standard conformity issues: These will be hard to fix.
>
> What are the issues here?
Some of these are small, like ./bits/types/sigevent_t.h's
sigev_notify_attributes not being pthread_attr_t*
Others need some work, like the missing SA_SIGINFO, for which we have
patches which need polishing and committing.
Others need implementing, like SA_NOCLDWAIT.
Others just need defining, like IUCLC, IXANY, etc.
There are a few remaining namespace issues due to missing __ marking or
spurious #includes.
So those, we can fix them.
Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's
l_type/l_whence being int instead of short.
There is also sys/un.h which defines a sun_len field, which IIRC is to
be expected on BSD systems, but not defined in Posix?
Also, ioctl takes (int, unsigned long int, ...) but
./conform/XPG42/stropts.h/conform.out wants (int, int, ...)?
> > - elf/check-localplt: There will always be PLTs to libhurd/machuser.so
> > anyway.
>
> If a library has *local* PLT entries -
Ah. I got confused by the presence of __vm_allocate which is an RPC,
but we actually have a non-RPC version inside libc.so itself. There are
a hundred of them mostly in libc.so, ld.so, libpthread.so
> PLT entries for within-library calls to other functions in that shared
> library - that are hard to fix to use hidden aliases, it's expected
> that the localplt.data files will list those as expected
Ok.
> > - elf/check-execstack: We have nested functions which make the stack
> > executable indeed.
>
> That's pointers to nested functions involving creation of trampolines?
Yes.
> Do those nested functions actually improve the code
Yes. There are notably callbacks whose parameters don't permit to get
the context parameters etc.
> Do all libraries have these or only some?
Only libc.so, ld.so and libpthread.so have them.
> > - check-abi-libmachuser, check-abi-libhurduser: These actually depend on
> > .defs files in gnumach and hurd, so we can't really define ABI files.
>
> Depend in what way? Are you saying they export different symbols
> depending on the versions of gnumach and hurd glibc is built with?
That is it, yes.
> How are symbol versions for such extra symbols determined - based on
> gnumach and hurd versions instead of glibc versions?
That was not actually settled, but I guess it should be gnumach and hurd
versions.
> maybe those packages need to install ABI baselines for the glibc tests
> (or something like that).
Indeed.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 14:47 ` Samuel Thibault
@ 2018-04-02 16:01 ` H.J. Lu
2018-04-02 16:16 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: H.J. Lu @ 2018-04-02 16:01 UTC (permalink / raw)
To: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Hello,
>
> Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote:
>> On Mon, 2 Apr 2018, Samuel Thibault wrote:
>>
>> > This means that build-glibcs i686-gnu now builds fine. Among the
>> > remaining TODOs, there are
>>
>> Thanks! I'd add: the "requires out-of-tree patches" statement in README
>> needs to be removed,
>
> Oh, I was unaware of that mention.
>
>
mig master branch failed to build on Fedora 27:
gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o
parser.o routine.o server.o statement.o string.o type.o user.o utils.o
vprint.o
/usr/local/bin/ld: lexxer.o: in function `yylex':
/export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834:
undefined reference to `yywrap'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:495: migcom] Error 1
H.J.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 15:50 ` Samuel Thibault
@ 2018-04-02 16:13 ` Samuel Thibault
2018-04-03 0:13 ` Joseph Myers
2018-04-03 0:10 ` Joseph Myers
1 sibling, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-04-02 16:13 UTC (permalink / raw)
To: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
Samuel Thibault, on lun. 02 avril 2018 17:50:17 +0200, wrote:
> There are a few remaining namespace issues due to missing __ marking or
> spurious #includes.
One issue is with struct sched_param. The __sched_param definition
was removed in glibc while htl's pthread_attr uses it. For now I just
made struct___pthread_attr.h include <sched.h> but that brings things
unwanted for <sys/types.h> (which is supposed to pull pthread_attr).
So I guess we should revert to defining __sched_param?
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 16:01 ` H.J. Lu
@ 2018-04-02 16:16 ` Samuel Thibault
2018-04-02 17:06 ` H.J. Lu
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-04-02 16:16 UTC (permalink / raw)
To: H.J. Lu
Cc: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote:
> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > Hello,
> >
> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote:
> >> On Mon, 2 Apr 2018, Samuel Thibault wrote:
> >>
> >> > This means that build-glibcs i686-gnu now builds fine. Among the
> >> > remaining TODOs, there are
> >>
> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README
> >> needs to be removed,
> >
> > Oh, I was unaware of that mention.
>
> mig master branch failed to build on Fedora 27:
>
> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o
> parser.o routine.o server.o statement.o string.o type.o user.o utils.o
> vprint.o
> /usr/local/bin/ld: lexxer.o: in function `yylex':
> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834:
> undefined reference to `yywrap'
Could you post config.log? configure is supposed to detect this:
checking lex library... -lfl
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 16:16 ` Samuel Thibault
@ 2018-04-02 17:06 ` H.J. Lu
2018-04-02 17:16 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: H.J. Lu @ 2018-04-02 17:06 UTC (permalink / raw)
To: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote:
>> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
>> > Hello,
>> >
>> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote:
>> >> On Mon, 2 Apr 2018, Samuel Thibault wrote:
>> >>
>> >> > This means that build-glibcs i686-gnu now builds fine. Among the
>> >> > remaining TODOs, there are
>> >>
>> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README
>> >> needs to be removed,
>> >
>> > Oh, I was unaware of that mention.
>>
>> mig master branch failed to build on Fedora 27:
>>
>> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o
>> parser.o routine.o server.o statement.o string.o type.o user.o utils.o
>> vprint.o
>> /usr/local/bin/ld: lexxer.o: in function `yylex':
>> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834:
>> undefined reference to `yywrap'
>
> Could you post config.log? configure is supposed to detect this:
>
> checking lex library... -lfl
>
checking lex library... none needed
--
H.J.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 17:06 ` H.J. Lu
@ 2018-04-02 17:16 ` Samuel Thibault
2018-04-02 17:22 ` H.J. Lu
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-04-02 17:16 UTC (permalink / raw)
To: H.J. Lu
Cc: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote:
> On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote:
> >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> >> > Hello,
> >> >
> >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote:
> >> >> On Mon, 2 Apr 2018, Samuel Thibault wrote:
> >> >>
> >> >> > This means that build-glibcs i686-gnu now builds fine. Among the
> >> >> > remaining TODOs, there are
> >> >>
> >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README
> >> >> needs to be removed,
> >> >
> >> > Oh, I was unaware of that mention.
> >>
> >> mig master branch failed to build on Fedora 27:
> >>
> >> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o
> >> parser.o routine.o server.o statement.o string.o type.o user.o utils.o
> >> vprint.o
> >> /usr/local/bin/ld: lexxer.o: in function `yylex':
> >> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834:
> >> undefined reference to `yywrap'
> >
> > Could you post config.log? configure is supposed to detect this:
> >
> > checking lex library... -lfl
>
> checking lex library... none needed
Please really config.log, not only the configure output.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 17:16 ` Samuel Thibault
@ 2018-04-02 17:22 ` H.J. Lu
2018-04-02 17:35 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: H.J. Lu @ 2018-04-02 17:22 UTC (permalink / raw)
To: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
On Mon, Apr 2, 2018 at 10:15 AM, Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote:
>> On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
>> > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote:
>> >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
>> >> > Hello,
>> >> >
>> >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote:
>> >> >> On Mon, 2 Apr 2018, Samuel Thibault wrote:
>> >> >>
>> >> >> > This means that build-glibcs i686-gnu now builds fine. Among the
>> >> >> > remaining TODOs, there are
>> >> >>
>> >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README
>> >> >> needs to be removed,
>> >> >
>> >> > Oh, I was unaware of that mention.
>> >>
>> >> mig master branch failed to build on Fedora 27:
>> >>
>> >> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o
>> >> parser.o routine.o server.o statement.o string.o type.o user.o utils.o
>> >> vprint.o
>> >> /usr/local/bin/ld: lexxer.o: in function `yylex':
>> >> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834:
>> >> undefined reference to `yywrap'
>> >
>> > Could you post config.log? configure is supposed to detect this:
>> >
>> > checking lex library... -lfl
>>
>> checking lex library... none needed
>
> Please really config.log, not only the configure output.
>
configure:4096: checking lex library
configure:4110: gcc -o conftest -g -O2 conftest.c >&5
/usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `input':
/export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:1185:
undefined reference to `yywrap'
/usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `yylex':
/export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:879:
undefined reference to `yywrap'
/usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `main':
/export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/conftest.l:18:
undefined reference to `yywrap'
collect2: error: ld returned 1 exit status
configure:4110: $? = 1
....
configure:4460: result: no
...
configure: exit 0
--
H.J.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 17:22 ` H.J. Lu
@ 2018-04-02 17:35 ` Samuel Thibault
2018-04-02 17:37 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-04-02 17:35 UTC (permalink / raw)
To: H.J. Lu
Cc: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
H.J. Lu, on lun. 02 avril 2018 10:22:31 -0700, wrote:
> On Mon, Apr 2, 2018 at 10:15 AM, Samuel Thibault
> <samuel.thibault@gnu.org> wrote:
> > H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote:
> >> On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> >> > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote:
> >> >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> >> >> > Hello,
> >> >> >
> >> >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote:
> >> >> >> On Mon, 2 Apr 2018, Samuel Thibault wrote:
> >> >> >>
> >> >> >> > This means that build-glibcs i686-gnu now builds fine. Among the
> >> >> >> > remaining TODOs, there are
> >> >> >>
> >> >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README
> >> >> >> needs to be removed,
> >> >> >
> >> >> > Oh, I was unaware of that mention.
> >> >>
> >> >> mig master branch failed to build on Fedora 27:
> >> >>
> >> >> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o
> >> >> parser.o routine.o server.o statement.o string.o type.o user.o utils.o
> >> >> vprint.o
> >> >> /usr/local/bin/ld: lexxer.o: in function `yylex':
> >> >> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834:
> >> >> undefined reference to `yywrap'
> >> >
> >> > Could you post config.log? configure is supposed to detect this:
> >> >
> >> > checking lex library... -lfl
> >>
> >> checking lex library... none needed
> >
> > Please really config.log, not only the configure output.
> >
>
> configure:4096: checking lex library
> configure:4110: gcc -o conftest -g -O2 conftest.c >&5
> /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `input':
> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:1185:
> undefined reference to `yywrap'
> /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `yylex':
> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:879:
> undefined reference to `yywrap'
> /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `main':
> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/conftest.l:18:
> undefined reference to `yywrap'
> collect2: error: ld returned 1 exit status
> configure:4110: $? = 1
> ....
> configure:4460: result: no
Please really post config.log (or send it privately). "result: no" here
is not related to "checking lex library".
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 17:35 ` Samuel Thibault
@ 2018-04-02 17:37 ` Samuel Thibault
0 siblings, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-04-02 17:37 UTC (permalink / raw)
To: H.J. Lu, Joseph Myers, Florian Weimer, Thomas Schwinge,
GNU C Library, bug-hurd, David Michael
Samuel Thibault, on lun. 02 avril 2018 19:35:11 +0200, wrote:
> > configure:4096: checking lex library
> > configure:4110: gcc -o conftest -g -O2 conftest.c >&5
> > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `input':
> > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:1185:
> > undefined reference to `yywrap'
> > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `yylex':
> > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:879:
> > undefined reference to `yywrap'
> > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `main':
> > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/conftest.l:18:
> > undefined reference to `yywrap'
> > collect2: error: ld returned 1 exit status
> > configure:4110: $? = 1
> > ....
> > configure:4460: result: no
>
> Please really post config.log (or send it privately). "result: no" here
> is not related to "checking lex library".
I guess you don't have libfl-devel on your system, and apparently
autoconf's programs.m4 doesn't actually handle that case.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 15:50 ` Samuel Thibault
2018-04-02 16:13 ` Samuel Thibault
@ 2018-04-03 0:10 ` Joseph Myers
2018-04-18 23:57 ` Samuel Thibault
1 sibling, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-04-03 0:10 UTC (permalink / raw)
To: Samuel Thibault
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On Mon, 2 Apr 2018, Samuel Thibault wrote:
> Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's
> l_type/l_whence being int instead of short.
Where something is problematic to fix, because a fix would break the ABI
or needs some external feature, there is an xfail mechanism internal to
the conform tests. It involves a bug being filed in Bugzilla for the
issue in question, an addition to conformtest-xfail-conds (conditional on
ifeq ($(subdir),conform)) in an appropriate sysdeps Makefile, with a
comment referencing the bug, and xfail[cond]- on the relevant expectation
in the relevant -data file, again with a comment referencing the bug.
For example:
// Bug 17786: st_dev has wrong type.
xfail[mips-o32-linux]-element {struct stat} dev_t st_dev
Before doing any such XFAILing, you should check that the expectation is
actually backed up by the relevant standard and that a fix really does
need an ABI change or a new feature. Also, this XFAIL mechanism can only
be used for positive expectations that are failing - it can't be used for
cases where the header violates the expected namespace.
> There is also sys/un.h which defines a sun_len field, which IIRC is to
> be expected on BSD systems, but not defined in Posix?
Well, in fact POSIX reserves sun_* for sys/un.h (note the reservations are
in a separate part of the standard from the main definitions of header
contents), so there's a bug in the expectations not allowing for it. This
illustrates the need for checking such failures against the standards to
see where the bug is.
> Also, ioctl takes (int, unsigned long int, ...) but
> ./conform/XPG42/stropts.h/conform.out wants (int, int, ...)?
That's already generically XFAILed with reference to bug 14362.
> > Do those nested functions actually improve the code
>
> Yes. There are notably callbacks whose parameters don't permit to get
> the context parameters etc.
>
> > Do all libraries have these or only some?
>
> Only libc.so, ld.so and libpthread.so have them.
Then maybe some mechanism is needed for sysdeps Makefiles to define
libraries expected to have executable stacks.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 16:13 ` Samuel Thibault
@ 2018-04-03 0:13 ` Joseph Myers
2018-04-17 22:50 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-04-03 0:13 UTC (permalink / raw)
To: Samuel Thibault
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On Mon, 2 Apr 2018, Samuel Thibault wrote:
> Samuel Thibault, on lun. 02 avril 2018 17:50:17 +0200, wrote:
> > There are a few remaining namespace issues due to missing __ marking or
> > spurious #includes.
>
> One issue is with struct sched_param. The __sched_param definition
> was removed in glibc while htl's pthread_attr uses it. For now I just
> made struct___pthread_attr.h include <sched.h> but that brings things
> unwanted for <sys/types.h> (which is supposed to pull pthread_attr).
>
> So I guess we should revert to defining __sched_param?
If you need, on Hurd, in installed headers, a type "struct __sched_param",
that would most naturally go in a Hurd-specific
bits/types/struct___sched_param.h. If that's not appropriate, please
explain the issue in more detail. Anything restoring the old __need_*
mechanism for any glibc-internal definitions is not appropriate (struct
__sched_param was removed as part of removing __need_*).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-02 0:10 ` Samuel Thibault
` (2 preceding siblings ...)
2018-04-02 14:22 ` Joseph Myers
@ 2018-04-03 15:45 ` Joseph Myers
2018-04-03 16:08 ` Samuel Thibault
2018-04-03 21:48 ` Joseph Myers
3 siblings, 2 replies; 87+ messages in thread
From: Joseph Myers @ 2018-04-03 15:45 UTC (permalink / raw)
To: Samuel Thibault
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On Mon, 2 Apr 2018, Samuel Thibault wrote:
> This means that build-glibcs i686-gnu now builds fine. Among the
> remaining TODOs, there are
If you use mainline GCC, however, it fails:
../sysdeps/mach/hurd/if_index.c: In function '__if_nametoindex':
../sysdeps/mach/hurd/if_index.c:40:3: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation]
strncpy (ifr.ifr_name, ifname, IFNAMSIZ);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-03 15:45 ` Joseph Myers
@ 2018-04-03 16:08 ` Samuel Thibault
2018-04-03 21:48 ` Joseph Myers
1 sibling, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-04-03 16:08 UTC (permalink / raw)
To: Joseph Myers
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
Joseph Myers, on mar. 03 avril 2018 15:45:13 +0000, wrote:
> On Mon, 2 Apr 2018, Samuel Thibault wrote:
>
> > This means that build-glibcs i686-gnu now builds fine. Among the
> > remaining TODOs, there are
>
> If you use mainline GCC, however, it fails:
>
> ../sysdeps/mach/hurd/if_index.c: In function '__if_nametoindex':
> ../sysdeps/mach/hurd/if_index.c:40:3: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation]
> strncpy (ifr.ifr_name, ifname, IFNAMSIZ);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Oh, a real bug indeed :)
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-03 15:45 ` Joseph Myers
2018-04-03 16:08 ` Samuel Thibault
@ 2018-04-03 21:48 ` Joseph Myers
2018-04-03 21:58 ` Samuel Thibault
1 sibling, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-04-03 21:48 UTC (permalink / raw)
To: Samuel Thibault
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
The build for i686-gnu also fails using GCC 6 branch with
build-many-glibcs.py:
hurdsig.c: In function 'interrupted_reply_port_location.isra.1':
hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
*(volatile mach_port_t *) portloc = *portloc;
^~~~~~~~
I haven't investigated whether this warning is valid, or whether it's
bogus (in which case we don't add initializations just to fix warnings,
but may used DIAG_*_NEEDS_COMMENT with appropriate explanations of what
warning appears and why it is bogus).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-03 21:48 ` Joseph Myers
@ 2018-04-03 21:58 ` Samuel Thibault
2018-04-03 22:07 ` Zack Weinberg
2018-04-05 11:07 ` Florian Weimer
0 siblings, 2 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-04-03 21:58 UTC (permalink / raw)
To: Joseph Myers
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
Joseph Myers, on mar. 03 avril 2018 21:48:32 +0000, wrote:
> The build for i686-gnu also fails using GCC 6 branch with
> build-many-glibcs.py:
>
> hurdsig.c: In function 'interrupted_reply_port_location.isra.1':
> hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> *(volatile mach_port_t *) portloc = *portloc;
> ^~~~~~~~
>
> I haven't investigated whether this warning is valid, or whether it's
> bogus
Well, it's completely bogus: portloc is initialized just above. I don't
understand why it wouldn't see that.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-03 21:58 ` Samuel Thibault
@ 2018-04-03 22:07 ` Zack Weinberg
2018-04-03 22:48 ` Joseph Myers
2018-04-05 11:07 ` Florian Weimer
1 sibling, 1 reply; 87+ messages in thread
From: Zack Weinberg @ 2018-04-03 22:07 UTC (permalink / raw)
To: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
On Tue, Apr 3, 2018 at 5:58 PM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Joseph Myers, on mar. 03 avril 2018 21:48:32 +0000, wrote:
>> The build for i686-gnu also fails using GCC 6 branch with
>> build-many-glibcs.py:
>>
>> hurdsig.c: In function 'interrupted_reply_port_location.isra.1':
>> hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> *(volatile mach_port_t *) portloc = *portloc;
>> ^~~~~~~~
>>
>> I haven't investigated whether this warning is valid, or whether it's
>> bogus
>
> Well, it's completely bogus: portloc is initialized just above. I don't
> understand why it wouldn't see that.
I think it thinks the *value pointed-to by portloc* is uninitialized.
Writing that value to a volatile memory location (which happens to be
the same memory location, but you specifically told it not to pay
attention to that with the volatile cast) is therefore invalid.
I don't know this code well enough to suggest what you might could do
about that. Since the warning does not happen with GCC 7 or 8 I would
be fine with suppressing the diagnostic.
zw
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-03 22:07 ` Zack Weinberg
@ 2018-04-03 22:48 ` Joseph Myers
0 siblings, 0 replies; 87+ messages in thread
From: Joseph Myers @ 2018-04-03 22:48 UTC (permalink / raw)
To: Zack Weinberg
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On Tue, 3 Apr 2018, Zack Weinberg wrote:
> On Tue, Apr 3, 2018 at 5:58 PM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > Joseph Myers, on mar. 03 avril 2018 21:48:32 +0000, wrote:
> >> The build for i686-gnu also fails using GCC 6 branch with
> >> build-many-glibcs.py:
> >>
> >> hurdsig.c: In function 'interrupted_reply_port_location.isra.1':
> >> hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >> *(volatile mach_port_t *) portloc = *portloc;
> >> ^~~~~~~~
> >>
> >> I haven't investigated whether this warning is valid, or whether it's
> >> bogus
> >
> > Well, it's completely bogus: portloc is initialized just above. I don't
> > understand why it wouldn't see that.
>
> I think it thinks the *value pointed-to by portloc* is uninitialized.
This is just after a call to _hurdsig_catch_memory_fault, which is a macro
involving a call to setjmp. I think the returns-twice nature of setjmp is
confusing the compiler into thinking portloc itself is uninitialized (I
don't know why this particular warning) - in fact, the second return of
setjmp will never reach the code getting the warning (as setjmp will
return nonzero, so _hurdsig_catch_memory_fault will).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-03 21:58 ` Samuel Thibault
2018-04-03 22:07 ` Zack Weinberg
@ 2018-04-05 11:07 ` Florian Weimer
1 sibling, 0 replies; 87+ messages in thread
From: Florian Weimer @ 2018-04-05 11:07 UTC (permalink / raw)
To: Joseph Myers, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On 04/03/2018 11:58 PM, Samuel Thibault wrote:
> Joseph Myers, on mar. 03 avril 2018 21:48:32 +0000, wrote:
>> The build for i686-gnu also fails using GCC 6 branch with
>> build-many-glibcs.py:
>>
>> hurdsig.c: In function 'interrupted_reply_port_location.isra.1':
>> hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> *(volatile mach_port_t *) portloc = *portloc;
>> ^~~~~~~~
>>
>> I haven't investigated whether this warning is valid, or whether it's
>> bogus
>
> Well, it's completely bogus: portloc is initialized just above. I don't
> understand why it wouldn't see that.
You will have to look at the GIMPLE or assembler to determine if the
warning is bogus after GCC has processed the setjmp call. It may very
well be the case that after those transformations, there *is* an
uninitialized use of portloc.
Suppressing the warning could be the wrong thing to do here. You may
have to declare portloc itself volatile.
Thanks a lot for all these Hurd changes, by the way. I really
appreciate your work.
Thanks,
Florian
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-03 0:13 ` Joseph Myers
@ 2018-04-17 22:50 ` Samuel Thibault
2018-04-17 23:02 ` Joseph Myers
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-04-17 22:50 UTC (permalink / raw)
To: Joseph Myers
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
Hello,
Joseph Myers, le mar. 03 avril 2018 00:13:43 +0000, a ecrit:
> On Mon, 2 Apr 2018, Samuel Thibault wrote:
> > Samuel Thibault, on lun. 02 avril 2018 17:50:17 +0200, wrote:
> > > There are a few remaining namespace issues due to missing __ marking or
> > > spurious #includes.
> >
> > One issue is with struct sched_param. The __sched_param definition
> > was removed in glibc while htl's pthread_attr uses it. For now I just
> > made struct___pthread_attr.h include <sched.h> but that brings things
> > unwanted for <sys/types.h> (which is supposed to pull pthread_attr).
> >
> > So I guess we should revert to defining __sched_param?
>
> If you need, on Hurd, in installed headers, a type "struct __sched_param",
> that would most naturally go in a Hurd-specific
> bits/types/struct___sched_param.h.
Well, there is actually nothing hurd-specific in struct sched_param,
except the fact that the __sched_param name is needed so
sys/types.h can have pthread_attr (which uses it) without exposing
sched_param, as required by some levels of standard (e.g.
./conform/POSIX/fcntl.h/conform.out complains about the presence of
sched_param currently). Linux doesn't have that issue because it just
always completely hides the content of pthread types.
The patch below would just introduce bits/types/struct___sched_param.h.
and bits/types/struct_sched_param.h for all ports since it's the same.
> Anything restoring the old __need_* mechanism for any glibc-internal
> definitions is not appropriate
Sure!
Samuel
diff --git a/bits/sched.h b/bits/sched.h
index 8d9f077eee..bdd94c969d 100644
--- a/bits/sched.h
+++ b/bits/sched.h
@@ -29,10 +29,6 @@
#define SCHED_FIFO 1
#define SCHED_RR 2
-/* Data structure to describe a process' schedulability. */
-struct sched_param
-{
- int sched_priority;
-};
+#include <bits/types/struct_sched_param.h>
#endif /* bits/sched.h */
diff --git a/bits/types/struct___sched_param.h b/bits/types/struct___sched_param.h
new file mode 100644
index 0000000000..a6d95bfd61
--- /dev/null
+++ b/bits/types/struct___sched_param.h
@@ -0,0 +1,28 @@
+/* Sched parameter structure. Generic version.
+ Copyright (C) 1996-2018 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <http://www.gnu.org/licenses/>. */
+
+#ifndef _BITS_TYPES_STRUCT___SCHED_PARAM
+#define _BITS_TYPES_STRUCT___SCHED_PARAM 1
+
+/* Data structure to describe a process' schedulability. */
+struct __sched_param
+{
+ int __sched_priority;
+};
+
+#endif /* bits/types/struct___sched_param.h */
diff --git a/bits/types/struct_sched_param.h b/bits/types/struct_sched_param.h
new file mode 100644
index 0000000000..416d8bf8c4
--- /dev/null
+++ b/bits/types/struct_sched_param.h
@@ -0,0 +1,27 @@
+/* Sched parameter structure. Generic version.
+ Copyright (C) 1996-2018 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <http://www.gnu.org/licenses/>. */
+
+#ifndef _BITS_TYPES_STRUCT_SCHED_PARAM
+#define _BITS_TYPES_STRUCT_SCHED_PARAM 1
+
+#include <bits/types/struct___sched_param.h>
+/* Define the real names for the elements of `struct sched_param'. */
+#define sched_param __sched_param
+#define sched_priority __sched_priority
+
+#endif /* bits/types/struct_sched_param.h */
diff --git a/posix/Makefile b/posix/Makefile
index 51dcf129ec..2a1cb2dd47 100644
--- a/posix/Makefile
+++ b/posix/Makefile
@@ -31,7 +31,8 @@ headers := sys/utsname.h sys/times.h sys/wait.h sys/types.h unistd.h \
bits/local_lim.h tar.h bits/utsname.h bits/confname.h \
bits/waitflags.h bits/waitstatus.h sys/unistd.h sched.h \
bits/sched.h bits/cpu-set.h re_comp.h wait.h bits/environments.h \
- cpio.h spawn.h bits/unistd.h
+ cpio.h spawn.h bits/unistd.h \
+ bits/types/struct___sched_param.h bits/types/struct_sched_param.h
routines := \
uname \
diff --git a/posix/sched.h b/posix/sched.h
index 619b3b3a81..4d985ab37f 100644
--- a/posix/sched.h
+++ b/posix/sched.h
@@ -43,11 +43,6 @@ typedef __pid_t pid_t;
#include <bits/sched.h>
#include <bits/cpu-set.h>
-/* Backward compatibility. */
-#define sched_priority sched_priority
-#define __sched_priority sched_priority
-
-
__BEGIN_DECLS
/* Set scheduling parameters for a process. */
diff --git a/sysdeps/htl/bits/types/struct___pthread_attr.h b/sysdeps/htl/bits/types/struct___pthread_attr.h
index 2299c0179f..5c4b4e6c30 100644
--- a/sysdeps/htl/bits/types/struct___pthread_attr.h
+++ b/sysdeps/htl/bits/types/struct___pthread_attr.h
@@ -19,7 +19,7 @@
#ifndef _BITS_TYPES_STRUCT___PTHREAD_ATTR
#define _BITS_TYPES_STRUCT___PTHREAD_ATTR 1
-#include <sched.h>
+#include <bits/types/struct___sched_param.h>
#define __need_size_t
#include <stddef.h>
@@ -32,7 +32,7 @@ enum __pthread_contentionscope;
that not all of them are supported on all systems. */
struct __pthread_attr
{
- struct sched_param __schedparam;
+ struct __sched_param __schedparam;
void *__stackaddr;
size_t __stacksize;
size_t __guardsize;
diff --git a/sysdeps/htl/pt-attr.c b/sysdeps/htl/pt-attr.c
index 77ecc73465..fc39aa63d6 100644
--- a/sysdeps/htl/pt-attr.c
+++ b/sysdeps/htl/pt-attr.c
@@ -24,7 +24,7 @@
#include <pt-internal.h>
const struct __pthread_attr __pthread_default_attr = {
- __schedparam: { sched_priority: 0 },
+ __schedparam: { __sched_priority: 0 },
__stacksize: 0,
__stackaddr: NULL,
#ifdef PAGESIZE
diff --git a/sysdeps/htl/timer_routines.h b/sysdeps/htl/timer_routines.h
index a8134f510f..062128cf92 100644
--- a/sysdeps/htl/timer_routines.h
+++ b/sysdeps/htl/timer_routines.h
@@ -32,8 +32,8 @@ thread_attr_compare (const pthread_attr_t * left, const pthread_attr_t * right)
struct __pthread_attr *ileft = (struct __pthread_attr *) left;
struct __pthread_attr *iright = (struct __pthread_attr *) right;
- return ileft->__schedparam.sched_priority
- == iright->__schedparam.sched_priority
+ return ileft->__schedparam.__sched_priority
+ == iright->__schedparam.__sched_priority
&& ileft->__stackaddr == iright->__stackaddr
&& ileft->__stacksize == iright->__stacksize
&& ileft->__guardsize == iright->__guardsize
diff --git a/sysdeps/unix/sysv/linux/bits/sched.h b/sysdeps/unix/sysv/linux/bits/sched.h
index 24159c57b3..34f27a7d9b 100644
--- a/sysdeps/unix/sysv/linux/bits/sched.h
+++ b/sysdeps/unix/sysv/linux/bits/sched.h
@@ -71,11 +71,7 @@
# define CLONE_IO 0x80000000 /* Clone I/O context. */
#endif
-/* Data structure to describe a process' schedulability. */
-struct sched_param
-{
- int sched_priority;
-};
+#include <bits/types/struct_sched_param.h>
__BEGIN_DECLS
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-17 22:50 ` Samuel Thibault
@ 2018-04-17 23:02 ` Joseph Myers
2018-04-17 23:08 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-04-17 23:02 UTC (permalink / raw)
To: Samuel Thibault
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On Wed, 18 Apr 2018, Samuel Thibault wrote:
> The patch below would just introduce bits/types/struct___sched_param.h.
> and bits/types/struct_sched_param.h for all ports since it's the same.
A bits/types/struct_sched_param.h that does "#define sched_param
__sched_param" is not appropriate for Linux, because it would change the
C++ mangling of struct sched_param.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-17 23:02 ` Joseph Myers
@ 2018-04-17 23:08 ` Samuel Thibault
2018-04-18 11:13 ` Joseph Myers
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-04-17 23:08 UTC (permalink / raw)
To: Joseph Myers
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
Joseph Myers, le mar. 17 avril 2018 23:02:45 +0000, a ecrit:
> On Wed, 18 Apr 2018, Samuel Thibault wrote:
>
> > The patch below would just introduce bits/types/struct___sched_param.h.
> > and bits/types/struct_sched_param.h for all ports since it's the same.
>
> A bits/types/struct_sched_param.h that does "#define sched_param
> __sched_param" is not appropriate for Linux, because it would change the
> C++ mangling of struct sched_param.
Oh.
So that could be as per below?
(the idea is to keep __sched_param close to sched_param so any future
extension would be done alongside).
Samuel
diff --git a/bits/sched.h b/bits/sched.h
index 8d9f077eee..bdd94c969d 100644
--- a/bits/sched.h
+++ b/bits/sched.h
@@ -29,10 +29,6 @@
#define SCHED_FIFO 1
#define SCHED_RR 2
-/* Data structure to describe a process' schedulability. */
-struct sched_param
-{
- int sched_priority;
-};
+#include <bits/types/struct_sched_param.h>
#endif /* bits/sched.h */
diff --git a/bits/types/struct___sched_param.h b/bits/types/struct___sched_param.h
new file mode 100644
index 0000000000..a6d95bfd61
--- /dev/null
+++ b/bits/types/struct___sched_param.h
@@ -0,0 +1,28 @@
+/* Sched parameter structure. Generic version.
+ Copyright (C) 1996-2018 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <http://www.gnu.org/licenses/>. */
+
+#ifndef _BITS_TYPES_STRUCT___SCHED_PARAM
+#define _BITS_TYPES_STRUCT___SCHED_PARAM 1
+
+/* Data structure to describe a process' schedulability. */
+struct __sched_param
+{
+ int __sched_priority;
+};
+
+#endif /* bits/types/struct___sched_param.h */
diff --git a/bits/types/struct_sched_param.h b/bits/types/struct_sched_param.h
new file mode 100644
index 0000000000..60707023d5
--- /dev/null
+++ b/bits/types/struct_sched_param.h
@@ -0,0 +1,28 @@
+/* Sched parameter structure. Generic version.
+ Copyright (C) 1996-2018 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <http://www.gnu.org/licenses/>. */
+
+#ifndef _BITS_TYPES_STRUCT_SCHED_PARAM
+#define _BITS_TYPES_STRUCT_SCHED_PARAM 1
+
+/* Data structure to describe a process' schedulability. */
+struct sched_param
+{
+ int sched_priority;
+};
+
+#endif /* bits/types/struct_sched_param.h */
diff --git a/posix/Makefile b/posix/Makefile
index 51dcf129ec..2a1cb2dd47 100644
--- a/posix/Makefile
+++ b/posix/Makefile
@@ -31,7 +31,8 @@ headers := sys/utsname.h sys/times.h sys/wait.h sys/types.h unistd.h \
bits/local_lim.h tar.h bits/utsname.h bits/confname.h \
bits/waitflags.h bits/waitstatus.h sys/unistd.h sched.h \
bits/sched.h bits/cpu-set.h re_comp.h wait.h bits/environments.h \
- cpio.h spawn.h bits/unistd.h
+ cpio.h spawn.h bits/unistd.h \
+ bits/types/struct___sched_param.h bits/types/struct_sched_param.h
routines := \
uname \
diff --git a/sysdeps/htl/bits/types/struct___pthread_attr.h b/sysdeps/htl/bits/types/struct___pthread_attr.h
index 2299c0179f..5c4b4e6c30 100644
--- a/sysdeps/htl/bits/types/struct___pthread_attr.h
+++ b/sysdeps/htl/bits/types/struct___pthread_attr.h
@@ -19,7 +19,7 @@
#ifndef _BITS_TYPES_STRUCT___PTHREAD_ATTR
#define _BITS_TYPES_STRUCT___PTHREAD_ATTR 1
-#include <sched.h>
+#include <bits/types/struct___sched_param.h>
#define __need_size_t
#include <stddef.h>
@@ -32,7 +32,7 @@ enum __pthread_contentionscope;
that not all of them are supported on all systems. */
struct __pthread_attr
{
- struct sched_param __schedparam;
+ struct __sched_param __schedparam;
void *__stackaddr;
size_t __stacksize;
size_t __guardsize;
diff --git a/sysdeps/htl/pt-attr.c b/sysdeps/htl/pt-attr.c
index 77ecc73465..fc39aa63d6 100644
--- a/sysdeps/htl/pt-attr.c
+++ b/sysdeps/htl/pt-attr.c
@@ -24,7 +24,7 @@
#include <pt-internal.h>
const struct __pthread_attr __pthread_default_attr = {
- __schedparam: { sched_priority: 0 },
+ __schedparam: { __sched_priority: 0 },
__stacksize: 0,
__stackaddr: NULL,
#ifdef PAGESIZE
diff --git a/sysdeps/htl/timer_routines.h b/sysdeps/htl/timer_routines.h
index a8134f510f..062128cf92 100644
--- a/sysdeps/htl/timer_routines.h
+++ b/sysdeps/htl/timer_routines.h
@@ -32,8 +32,8 @@ thread_attr_compare (const pthread_attr_t * left, const pthread_attr_t * right)
struct __pthread_attr *ileft = (struct __pthread_attr *) left;
struct __pthread_attr *iright = (struct __pthread_attr *) right;
- return ileft->__schedparam.sched_priority
- == iright->__schedparam.sched_priority
+ return ileft->__schedparam.__sched_priority
+ == iright->__schedparam.__sched_priority
&& ileft->__stackaddr == iright->__stackaddr
&& ileft->__stacksize == iright->__stacksize
&& ileft->__guardsize == iright->__guardsize
diff --git a/sysdeps/unix/sysv/linux/bits/sched.h b/sysdeps/unix/sysv/linux/bits/sched.h
index 24159c57b3..34f27a7d9b 100644
--- a/sysdeps/unix/sysv/linux/bits/sched.h
+++ b/sysdeps/unix/sysv/linux/bits/sched.h
@@ -71,11 +71,7 @@
# define CLONE_IO 0x80000000 /* Clone I/O context. */
#endif
-/* Data structure to describe a process' schedulability. */
-struct sched_param
-{
- int sched_priority;
-};
+#include <bits/types/struct_sched_param.h>
__BEGIN_DECLS
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-17 23:08 ` Samuel Thibault
@ 2018-04-18 11:13 ` Joseph Myers
2018-04-18 13:54 ` Zack Weinberg
0 siblings, 1 reply; 87+ messages in thread
From: Joseph Myers @ 2018-04-18 11:13 UTC (permalink / raw)
To: Samuel Thibault
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
On Wed, 18 Apr 2018, Samuel Thibault wrote:
> Joseph Myers, le mar. 17 avril 2018 23:02:45 +0000, a ecrit:
> > On Wed, 18 Apr 2018, Samuel Thibault wrote:
> >
> > > The patch below would just introduce bits/types/struct___sched_param.h.
> > > and bits/types/struct_sched_param.h for all ports since it's the same.
> >
> > A bits/types/struct_sched_param.h that does "#define sched_param
> > __sched_param" is not appropriate for Linux, because it would change the
> > C++ mangling of struct sched_param.
>
> Oh.
>
> So that could be as per below?
That seems plausible (this is not a review of this patch).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-18 11:13 ` Joseph Myers
@ 2018-04-18 13:54 ` Zack Weinberg
2018-04-18 14:03 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Zack Weinberg @ 2018-04-18 13:54 UTC (permalink / raw)
To: Joseph Myers
Cc: Samuel Thibault, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
On Wed, Apr 18, 2018 at 7:13 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Wed, 18 Apr 2018, Samuel Thibault wrote:
>
>> Joseph Myers, le mar. 17 avril 2018 23:02:45 +0000, a ecrit:
>> > On Wed, 18 Apr 2018, Samuel Thibault wrote:
>> >
>> > > The patch below would just introduce bits/types/struct___sched_param.h.
>> > > and bits/types/struct_sched_param.h for all ports since it's the same.
>> >
>> > A bits/types/struct_sched_param.h that does "#define sched_param
>> > __sched_param" is not appropriate for Linux, because it would change the
>> > C++ mangling of struct sched_param.
>>
>> Oh.
>>
>> So that could be as per below?
>
> That seems plausible (this is not a review of this patch).
I have a concern: the types 'struct sched_param' and 'struct
__sched_param' are not compatible, even if their members are identical
(6.2.7p1 explicitly requires the tags to be the same for
compatibility).So if you have a 'struct __sched_param' embedded in
your pthread_attr_t, all of the code that copies between that field
and parameters or variables named 'struct sched_param' must do so
field-by-field or with 'memcpy'. The compiler won't let you do a
straight-up structure assignment, but trying to get around that with
pointer tricks will produce undefined behavior.
zw
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-18 13:54 ` Zack Weinberg
@ 2018-04-18 14:03 ` Samuel Thibault
2018-04-18 18:40 ` Zack Weinberg
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-04-18 14:03 UTC (permalink / raw)
To: Zack Weinberg
Cc: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
Zack Weinberg, le mer. 18 avril 2018 09:54:53 -0400, a ecrit:
> On Wed, Apr 18, 2018 at 7:13 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Wed, 18 Apr 2018, Samuel Thibault wrote:
> >
> >> Joseph Myers, le mar. 17 avril 2018 23:02:45 +0000, a ecrit:
> >> > On Wed, 18 Apr 2018, Samuel Thibault wrote:
> >> >
> >> > > The patch below would just introduce bits/types/struct___sched_param.h.
> >> > > and bits/types/struct_sched_param.h for all ports since it's the same.
> >> >
> >> > A bits/types/struct_sched_param.h that does "#define sched_param
> >> > __sched_param" is not appropriate for Linux, because it would change the
> >> > C++ mangling of struct sched_param.
> >>
> >> Oh.
> >>
> >> So that could be as per below?
> >
> > That seems plausible (this is not a review of this patch).
>
> I have a concern: the types 'struct sched_param' and 'struct
> __sched_param' are not compatible, even if their members are identical
> (6.2.7p1 explicitly requires the tags to be the same for
> compatibility).
Ah, probably that's why bits/sched.h used to define both sched_param and
__sched_param with the __sched_priority field, and #define
sched_priority to __sched_priority. I can do that, it's fine.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-18 14:03 ` Samuel Thibault
@ 2018-04-18 18:40 ` Zack Weinberg
2018-04-18 18:53 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Zack Weinberg @ 2018-04-18 18:40 UTC (permalink / raw)
To: Zack Weinberg, Joseph Myers, Florian Weimer, Thomas Schwinge,
GNU C Library, bug-hurd, David Michael
On Wed, Apr 18, 2018 at 10:03 AM, Samuel Thibault
<samuel.thibault@gnu.org> wrote:
>>
>> I have a concern: the types 'struct sched_param' and 'struct
>> __sched_param' are not compatible, even if their members are identical
>> (6.2.7p1 explicitly requires the tags to be the same for
>> compatibility).
>
> Ah, probably that's why bits/sched.h used to define both sched_param and
> __sched_param with the __sched_priority field, and #define
> sched_priority to __sched_priority. I can do that, it's fine.
This is actually worse than having struct sched_param defined by
sys/types.h, because sched.h is now defining *macro* names that it's
not supposed to. It's far more likely that a program will try to
define a variable named 'sched_priority' than that it will try to
define its own 'struct sched_param'.
Can I ask whether you want to keep exposing the internals of pthread_*
types to applications? If there's a plan to stop doing that - even a
"yeah but it's hard and we have so many other things to do first"
intention - then I would recommend leaving sched_param alone for now
and just XFAILing the conformance test. On the other hand, if you
actively want to keep them exposed and encourage applications to use
them, then there does need to be some kind of workaround.
zw
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-18 18:40 ` Zack Weinberg
@ 2018-04-18 18:53 ` Samuel Thibault
0 siblings, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-04-18 18:53 UTC (permalink / raw)
To: Zack Weinberg
Cc: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
Zack Weinberg, le mer. 18 avril 2018 14:40:29 -0400, a ecrit:
> On Wed, Apr 18, 2018 at 10:03 AM, Samuel Thibault
> <samuel.thibault@gnu.org> wrote:
> >>
> >> I have a concern: the types 'struct sched_param' and 'struct
> >> __sched_param' are not compatible, even if their members are identical
> >> (6.2.7p1 explicitly requires the tags to be the same for
> >> compatibility).
> >
> > Ah, probably that's why bits/sched.h used to define both sched_param and
> > __sched_param with the __sched_priority field, and #define
> > sched_priority to __sched_priority. I can do that, it's fine.
>
> This is actually worse than having struct sched_param defined by
> sys/types.h, because sched.h is now defining *macro* names that it's
> not supposed to. It's far more likely that a program will try to
> define a variable named 'sched_priority' than that it will try to
> define its own 'struct sched_param'.
Sure. glibc just has been #defining sched_priority for a very long time
already :)
> Can I ask whether you want to keep exposing the internals of pthread_*
> types to applications? If there's a plan to stop doing that - even a
> "yeah but it's hard and we have so many other things to do first"
> intention - then I would recommend leaving sched_param alone for now
> and just XFAILing the conformance test.
That's it indeed.
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-03 0:10 ` Joseph Myers
@ 2018-04-18 23:57 ` Samuel Thibault
2018-04-21 8:54 ` Samuel Thibault
0 siblings, 1 reply; 87+ messages in thread
From: Samuel Thibault @ 2018-04-18 23:57 UTC (permalink / raw)
To: Joseph Myers
Cc: Florian Weimer, Thomas Schwinge, GNU C Library, bug-hurd, David Michael
Joseph Myers, le mar. 03 avril 2018 00:10:30 +0000, a ecrit:
> On Mon, 2 Apr 2018, Samuel Thibault wrote:
> > Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's
> > l_type/l_whence being int instead of short.
>
> Where something is problematic to fix, because a fix would break the ABI
> or needs some external feature, there is an xfail mechanism internal to
> the conform tests.
Ok, thanks for the info, I could work it out :)
There are some ABI-compatible changes which can be made. One of them is
struct shmid_ds's shm_segsz which is int but should be size_t. That is
defined as int in both ./sysvipc/sys/shm.h and ./sysdeps/gnu/bits/shm.h.
I have checked that the kfreebsd port uses its own shm.h that defines it
to size_t. I'd tend to think that we do not have any 64bit port using
./sysvipc/sys/shm.h or ./sysdeps/gnu/bits/shm.h, and thus we can just
fix them into size_t since on 32bit ports it is ABI-compatible with int?
(except the bitness, but I guess it does not problems in practice?)
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Upstreaming the glibc Hurd port
2018-04-18 23:57 ` Samuel Thibault
@ 2018-04-21 8:54 ` Samuel Thibault
0 siblings, 0 replies; 87+ messages in thread
From: Samuel Thibault @ 2018-04-21 8:54 UTC (permalink / raw)
To: Joseph Myers, Florian Weimer, Thomas Schwinge, GNU C Library,
bug-hurd, David Michael
Hello,
Samuel Thibault, le jeu. 19 avril 2018 01:57:49 +0200, a ecrit:
> I'd tend to think that we do not have any 64bit port using
> ./sysvipc/sys/shm.h
(I meant include/bits/shm.h here)
> or ./sysdeps/gnu/bits/shm.h, and thus we can just fix them into size_t
> since on 32bit ports it is ABI-compatible with int? (except the
> bitness, but I guess it does not problems in practice?)
ping?
(Linux has its own bits/shm.h, the kfreebsd port has its own bits/shm.h)
Samuel
^ permalink raw reply [flat|nested] 87+ messages in thread
end of thread, other threads:[~2018-04-21 8:54 UTC | newest]
Thread overview: 87+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-18 12:39 Upstreaming the glibc Hurd port Florian Weimer
2018-01-18 12:45 ` Samuel Thibault
2018-01-18 12:58 ` Florian Weimer
2018-01-18 13:47 ` Joseph Myers
2018-01-18 13:52 ` Joseph Myers
2018-01-18 13:59 ` Samuel Thibault
2018-01-18 13:58 ` Samuel Thibault
2018-01-18 14:03 ` Joseph Myers
2018-01-28 18:40 ` Samuel Thibault
2018-01-18 14:22 ` Thomas Schwinge
2018-01-18 14:27 ` Samuel Thibault
2018-01-18 15:14 ` Samuel Thibault
2018-01-18 15:35 ` Joseph Myers
2018-01-18 15:42 ` Samuel Thibault
2018-01-18 16:48 ` Joseph Myers
2018-01-18 16:59 ` Samuel Thibault
2018-01-18 23:16 ` Joseph Myers
2018-01-18 23:59 ` Samuel Thibault
2018-01-19 0:34 ` Joseph Myers
2018-01-19 10:10 ` Thomas Schwinge
2018-01-19 12:35 ` Manolis Ragkousis
2018-01-19 13:08 ` Joseph Myers
2018-01-19 14:11 ` Thomas Schwinge
2018-01-19 15:12 ` Joseph Myers
2018-01-19 18:24 ` Zack Weinberg
2018-01-19 18:30 ` Joseph Myers
2018-01-19 17:23 ` Joseph Myers
2018-01-19 17:32 ` Samuel Thibault
2018-01-19 17:50 ` Joseph Myers
2018-01-19 17:59 ` Samuel Thibault
2018-01-24 1:10 ` Samuel Thibault
2018-01-24 1:26 ` Joseph Myers
2018-01-24 1:27 ` Samuel Thibault
2018-01-25 1:41 ` Samuel Thibault
2018-01-25 15:43 ` Joseph Myers
2018-01-25 16:12 ` Joseph Myers
2018-01-25 16:20 ` Samuel Thibault
2018-03-19 1:51 ` Samuel Thibault
2018-03-19 15:36 ` Zack Weinberg
2018-03-19 15:47 ` Samuel Thibault
2018-03-19 15:54 ` Zack Weinberg
2018-03-19 16:05 ` Samuel Thibault
2018-03-26 23:13 ` Rafal Luzynski
2018-03-27 7:45 ` Samuel Thibault
2018-03-27 9:01 ` Samuel Thibault
2018-03-27 10:40 ` Rafal Luzynski
2018-03-27 10:43 ` Samuel Thibault
2018-03-27 10:53 ` Rafal Luzynski
2018-03-27 14:46 ` Tulio Magno Quites Machado Filho
2018-03-27 14:53 ` Carlos O'Donell
2018-03-27 16:31 ` Samuel Thibault
2018-04-02 0:10 ` Samuel Thibault
2018-04-02 7:51 ` Florian Weimer
2018-04-02 8:24 ` Samuel Thibault
2018-04-02 14:17 ` Joseph Myers
2018-04-02 15:50 ` Samuel Thibault
2018-04-02 16:13 ` Samuel Thibault
2018-04-03 0:13 ` Joseph Myers
2018-04-17 22:50 ` Samuel Thibault
2018-04-17 23:02 ` Joseph Myers
2018-04-17 23:08 ` Samuel Thibault
2018-04-18 11:13 ` Joseph Myers
2018-04-18 13:54 ` Zack Weinberg
2018-04-18 14:03 ` Samuel Thibault
2018-04-18 18:40 ` Zack Weinberg
2018-04-18 18:53 ` Samuel Thibault
2018-04-03 0:10 ` Joseph Myers
2018-04-18 23:57 ` Samuel Thibault
2018-04-21 8:54 ` Samuel Thibault
2018-04-02 14:22 ` Joseph Myers
2018-04-02 14:47 ` Samuel Thibault
2018-04-02 16:01 ` H.J. Lu
2018-04-02 16:16 ` Samuel Thibault
2018-04-02 17:06 ` H.J. Lu
2018-04-02 17:16 ` Samuel Thibault
2018-04-02 17:22 ` H.J. Lu
2018-04-02 17:35 ` Samuel Thibault
2018-04-02 17:37 ` Samuel Thibault
2018-04-03 15:45 ` Joseph Myers
2018-04-03 16:08 ` Samuel Thibault
2018-04-03 21:48 ` Joseph Myers
2018-04-03 21:58 ` Samuel Thibault
2018-04-03 22:07 ` Zack Weinberg
2018-04-03 22:48 ` Joseph Myers
2018-04-05 11:07 ` Florian Weimer
2018-01-18 14:33 ` Samuel Thibault
2018-01-18 15:24 ` 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).