kfreebsd-gnu etc. issues

kfreebsd-gnu etc. issues

[Joseph S. Myers]

I'm trying to stop non-Linux GCC targets from using config/linux.h and
other headers whose names indicate they relate to the Linux kernel,
separating GNU-userspace and Linux-kernel configuration more cleanly.
<http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02055.html> is the
initial patch in this series, and in the course of working on the
corresponding changes for i386/linux.h and i386/linux64.h I found
several possible problems with the configurations for *-kfreebsd-gnu,
*-knetbsd-gnu and *-kopensolaris-gnu.

* The headers config/kfreebsd-gnu.h etc. override
  GLIBC_DYNAMIC_LINKER.  But the 64-bit configurations
  x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to
  use any header that would override GLIBC_DYNAMIC_LINKER32 and
  GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h
  actually uses.  Thus those configurations would use Linux-specific
  dynamic linker settings, which seems unlikely to be as intended.

* These configurations use file_end_indicate_exec_stack to use the
  PT_GNU_STACK convention.  While some of the implementation of this
  is in the GNU linker and glibc, it also requires kernel support for
  correct operation.  Do all these kernels support this convention, or
  should this code actually be disabled for them in GCC and glibc?

* The kfreebsd-gnu and knetbsd-gnu configurations use linux-unwind.h
  (kopensolaris-gnu disables this).  They define REG_NAME to adapt
  linux-unwind.h to their system headers.  But linux-unwind.h also
  contains hardcoded checks for the particular instructions, complete
  with hardcoded Linux syscall numbers, in Linux signal trampolines.
  Do the FreeBSD and NetBSD kernels really use identical instructions?
  Does this code do anything useful on those systems?  If it's useful
  (possibly with some fixes) then linux-unwind.h ought to be renamed;
  otherwise those configurations should not be using it.

* A minor point: TARGET_VERSION, referring to Linux, is not overridden
  by these configurations.

If these issues can be fixed by someone who knows what is correct for
those targets then it would help with this cleanup - and while such
rearrangements of headers used on GNU/Linux may best be avoided in
development Stage 4, it should be fine to make changes then that are
only relevant to kfreebsd-gnu, knetbsd-gnu and kopensolaris-gnu.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: kfreebsd-gnu etc. issues

[Robert Millan]

Hi Joseph,

2011/1/1 Joseph S. Myers <joseph@codesourcery.com>:
> I'm trying to stop non-Linux GCC targets from using config/linux.h and
> other headers whose names indicate they relate to the Linux kernel,
> separating GNU-userspace and Linux-kernel configuration more cleanly.
> <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02055.html> is the
> initial patch in this series, and in the course of working on the
> corresponding changes for i386/linux.h and i386/linux64.h

Thank you for doing this.  As the person who introduced this
kind of use, I intended to propose something along these
lines myself, but never got the time to do it.

> I found
> several possible problems with the configurations for *-kfreebsd-gnu,
> *-knetbsd-gnu and *-kopensolaris-gnu.
>
> [...]

I can't review these problems right now, but I'll have a bit more
time in 1 or 2 weeks.  I'll get back to you.

-- 
Robert Millan

Re: kfreebsd-gnu etc. issues

[Robert Millan]

Hi Joseph

I'll look at more detail at the other problems, but first it
seems that non-Linux GNU targets are currently broken
because many declarations that are not Linux-specific
have been added to the Linux-specific sections of
config.gcc.

Should I wait untill your patch is merged to fix this?

Btw, your patch overhauls linux.h but not i386/linux64.h
which is in the same situation as you described.

-- 
Robert Millan

Re: kfreebsd-gnu etc. issues

[Joseph S. Myers]

On Wed, 12 Jan 2011, Robert Millan wrote:

> Hi Joseph
> 
> I'll look at more detail at the other problems, but first it
> seems that non-Linux GNU targets are currently broken
> because many declarations that are not Linux-specific
> have been added to the Linux-specific sections of
> config.gcc.

I don't think they are necessarily broken - and if they are, it is because 
of Linux-specific headers being used in non-Linux-specific code, not the 
other way round.

> Should I wait untill your patch is merged to fix this?

No.

> Btw, your patch overhauls linux.h but not i386/linux64.h
> which is in the same situation as you described.

Indeed.  While the subdirectory */*linux*.h headers that are used by 
non-Linux-kernel targets need splitting up, and removing from the headers 
used by non-Linux-kernel targets, separating this from splitting up the 
architecture-independent header leads to smaller patches such that it is 
easier for the author and patch reviewer to convince themselves that there 
are no unintended changes to semantics.

Furthermore, it was while looking at splitting up the i386/*.h headers 
that I found the issues raised in my message you're replying to.  And two 
of those four issues are issues where I am seeking information from 
someone familiar with the *-kfreebsd-gnu, *-knetbsd-gnu and 
*-kopensolaris-gnu targets in order to determine which definitions 
actually belong in Linux-kernel headers and which in GNU-userspace 
headers.  So if you could clarify the answers to my questions regarding 
PT_GNU_STACK and signal frames for those targets (with or without fixing 
any bugs for those targets indicated by the answers to those questions), 
that would help determine the correct division of those headers.

In turn, actually stopping non-Linux-kernel targets from using 
config/linux.h depends on splitting up the subdirectory linux.h files, 
because of how those interact with config/linux.h.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: kfreebsd-gnu etc. issues

[Robert Millan]

2011/1/12 Joseph S. Myers <joseph@codesourcery.com>:
> I don't think they are necessarily broken - and if they are, it is because
> of Linux-specific headers being used in non-Linux-specific code, not the
> other way round.

Actually, it's a different problem.  I'll just prepare a patch and
send it, it'll be obvious by reading the patch.

> So if you could clarify the answers to my questions regarding
> PT_GNU_STACK and signal frames for those targets (with or without fixing
> any bugs for those targets indicated by the answers to those questions),
> that would help determine the correct division of those headers.

Ok, I'll answer what I can in your previous mail.

-- 
Robert Millan

Re: kfreebsd-gnu etc. issues

[Robert Millan]

2011/1/1 Joseph S. Myers <joseph@codesourcery.com>:
> [...] I found
> several possible problems with the configurations for *-kfreebsd-gnu,
> *-knetbsd-gnu and *-kopensolaris-gnu.

Ok.  Unless indicated otherwise, my answers below apply to
*-kfreebsd-gnu, which is the only in these 3 systems that is
actively maintained.

For the other two I wouldn't worry about either guessing or
leaving them as-is.  If minor breakage happens it's unlikely
to bother anyone.

> * The headers config/kfreebsd-gnu.h etc. override
>  GLIBC_DYNAMIC_LINKER.  But the 64-bit configurations
>  x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to
>  use any header that would override GLIBC_DYNAMIC_LINKER32 and
>  GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h
>  actually uses.  Thus those configurations would use Linux-specific
>  dynamic linker settings, which seems unlikely to be as intended.

It's not as intended. On amd64 we use /lib/ld.so.1 and
/lib/ld-kfreebsd-x86-64.so.1.

> * These configurations use file_end_indicate_exec_stack to use the
>  PT_GNU_STACK convention.  While some of the implementation of this
>  is in the GNU linker and glibc, it also requires kernel support for
>  correct operation.  Do all these kernels support this convention, or
>  should this code actually be disabled for them in GCC and glibc?

I'm not familiar with PT_GNU_STACK.  Does a working
_dl_make_stack_executable() in glibc [1] indicate it's supported?

[1] http://svn.debian.org/viewsvn/glibc-bsd/trunk/glibc-ports/kfreebsd/dl-execstack.c?revision=1685&view=markup

> * The kfreebsd-gnu and knetbsd-gnu configurations use linux-unwind.h
>  (kopensolaris-gnu disables this).  They define REG_NAME to adapt
>  linux-unwind.h to their system headers.  But linux-unwind.h also
>  contains hardcoded checks for the particular instructions, complete
>  with hardcoded Linux syscall numbers, in Linux signal trampolines.

I'm sorry.  It seems this would be my fault (I introduced this with
the first kfreebsd-gnu port).

>  Do the FreeBSD and NetBSD kernels really use identical instructions?

Definitely not.  But it's strange we didn't notice, we've been using
it for several years.

>  Does this code do anything useful on those systems?  If it's useful
>  (possibly with some fixes) then linux-unwind.h ought to be renamed;

The only thing I know for sure is that those 2 syscalls don't work. Is
there any possibility that linux-unwind.h is useful for GNU/kFreeBSD
in its current state?

I don't understand this code, but what I can do is confirm that disabling
linux-unwind.h doesn't cause any breakage.  Then we could disable it
untill/unless someone more clued than me ports it to kFreeBSD.  Would
this be ok?

> * A minor point: TARGET_VERSION, referring to Linux, is not overridden
>  by these configurations.

Perhaps a common (or a fallback) string mentioning GNU and/or glibc
would fit.  But where's this displayed anyway?

-- 
Robert Millan

Re: kfreebsd-gnu etc. issues

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2386 bytes --]

On Wed, 12 Jan 2011, Robert Millan wrote:

> > * These configurations use file_end_indicate_exec_stack to use the
> >  PT_GNU_STACK convention.  While some of the implementation of this
> >  is in the GNU linker and glibc, it also requires kernel support for
> >  correct operation.  Do all these kernels support this convention, or
> >  should this code actually be disabled for them in GCC and glibc?
> 
> I'm not familiar with PT_GNU_STACK.  Does a working
> _dl_make_stack_executable() in glibc [1] indicate it's supported?

I think the glibc code is necessary but may not be sufficient; whatever 
kernel support there is or isn't, glibc needs to know how the kernel will 
have set things up (on Linux, based on PT_GNU_STACK for the dynamic 
linker, I think) in order to adjust it based on the PT_GNU_STACK of the 
executable and shared libraries.  Probably it's possible to get this right 
without kernel support (if glibc does the right things at startup), in 
which case we could consider this a GNU userspace convention.

> The only thing I know for sure is that those 2 syscalls don't work. Is
> there any possibility that linux-unwind.h is useful for GNU/kFreeBSD
> in its current state?

I don't see how it can be useful in its current state for any system using 
different syscall numbers.  Maybe the code using a ucontext would be 
relevant given code checking for different (kernel-dependent) 
instructions.

> I don't understand this code, but what I can do is confirm that disabling
> linux-unwind.h doesn't cause any breakage.  Then we could disable it
> untill/unless someone more clued than me ports it to kFreeBSD.  Would
> this be ok?

That makes sense to me.  If disabled for non-Linux-kernel targets, the 
REG_NAME abstraction may as well be removed as not actually being useful 
at present.

> > * A minor point: TARGET_VERSION, referring to Linux, is not overridden
> >  by these configurations.
> 
> Perhaps a common (or a fallback) string mentioning GNU and/or glibc
> would fit.  But where's this displayed anyway?

In collect2 (only, for these targets; mips-tdump and mips-tfile also use 
it).  I've also suggested that we should eliminate TARGET_VERSION 
completely (probably for 4.7) but while it's there, referring to Linux for 
these targets is wrong.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: kfreebsd-gnu etc. issues

[Robert Millan]

2011/1/12 Joseph S. Myers <joseph@codesourcery.com>:
>> I don't understand this code, but what I can do is confirm that disabling
>> linux-unwind.h doesn't cause any breakage.  Then we could disable it
>> untill/unless someone more clued than me ports it to kFreeBSD.  Would
>> this be ok?
>
> That makes sense to me.

Confirmed, linux-unwind.h can be removed.

> If disabled for non-Linux-kernel targets, the
> REG_NAME abstraction may as well be removed as not actually being useful
> at present.

Ack.  I'll send a patch for this.

-- 
Robert Millan

Re: kfreebsd-gnu etc. issues

[Ian Lance Taylor]

Robert Millan <rmh@gnu.org> writes:

> I'm not familiar with PT_GNU_STACK.  Does a working
> _dl_make_stack_executable() in glibc [1] indicate it's supported?
>
> [1] http://svn.debian.org/viewsvn/glibc-bsd/trunk/glibc-ports/kfreebsd/dl-execstack.c?revision=1685&view=markup

PT_GNU_STACK is a program header recognized by the Linux kernel when
loading an ELF executable or shared library.  If any executable or
shared library has a PT_GNU_STACK segment for which the PF_X bit is set
in the p_flags field, then the kernel will mark the stack as permitting
execution (i.e., will mmap it with PROT_EXEC as well as PROT_READ and
PROT_WRITE).

_dl_make_stack_executable is a related but distinct mechanism which is
used by the dynamic linker to make the stack executable when 1) the
stack was loaded as non-executable; 2) there is now some reason to make
the stack executable, e.g., a dlopen of a shared library which has a
PT_GNU_STACK header indicating that an executable stack is required.

As Joseph said, for the specific (and common) case of dynamically linked
binaries it's possible to make this work without kernel support, under
the assumption that the kernel runs the dynamic linker without an
executable stack.  However, for statically linked binaries, PT_GNU_STACK
is only useful if the kernel supports it.

All that said, I see little harm in using a PT_GNU_STACK header on
binaries even if the kernel does not fully support them.  Except for the
small amount of wasted space in every .o file and every executable, but
I lost that argument years ago.

Ian

Re: kfreebsd-gnu etc. issues

[Robert Millan]

2011/1/12 Ian Lance Taylor <iant@google.com>:
> All that said, I see little harm in using a PT_GNU_STACK header on
> binaries even if the kernel does not fully support them.  Except for the
> small amount of wasted space in every .o file and every executable, but
> I lost that argument years ago.

Thanks Ian.  Seeing that there's so little harm in enabling it
gratuitously, I think it'd be best to assume that PT_GNU_STACK
is supported unless someone can prove otherwise.

-- 
Robert Millan

Re: kfreebsd-gnu etc. issues

[Robert Millan]

2011/1/12 Robert Millan <rmh@gnu.org>:
>> * The headers config/kfreebsd-gnu.h etc. override
>>  GLIBC_DYNAMIC_LINKER.  But the 64-bit configurations
>>  x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to
>>  use any header that would override GLIBC_DYNAMIC_LINKER32 and
>>  GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h
>>  actually uses.  Thus those configurations would use Linux-specific
>>  dynamic linker settings, which seems unlikely to be as intended.
>
> It's not as intended. On amd64 we use /lib/ld.so.1 and
> /lib/ld-kfreebsd-x86-64.so.1.

It seems x86_64-kfreebsd-gnu has been broken for a while.  I
just realized that I wrote a patch to fix this in 2006 [1], but
somehow it was never merged in GCC (actually I'm not even
sure I submitted it).

In the meantime Debian GNU/kFreeBSD has been using this
patch to build GCC on their "kfreebsd-amd64" port.

I can prepare an updated version of this patch (relative to
trunk + your linux.h overhaul [2]).

[1] http://svn.debian.org/viewsvn/glibc-bsd/trunk/web/patches/upstream-only/gcc.diff?view=markup&pathrev=1424

[2] http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02055.html

-- 
Robert Millan

Re: kfreebsd-gnu etc. issues

[Joseph S. Myers]

On Fri, 14 Jan 2011, Robert Millan wrote:

> I can prepare an updated version of this patch (relative to
> trunk + your linux.h overhaul [2]).

Yes, that seems appropriate (it would now just be relevant to trunk since 
my gnu-user.h patch is now in trunk).

-- 
Joseph S. Myers
joseph@codesourcery.com