Re: kfreebsd-gnu etc. issues

2011/1/12 Joseph S. Myers : >> 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. Confi

Re: kfreebsd-gnu etc. issues

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 jos...@codesourcery.c

Re: kfreebsd-gnu etc. issues

2011/1/12 Ian Lance Taylor : > 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. Seei

Re: kfreebsd-gnu etc. issues

2011/1/12 Robert Millan : >> * 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,

Re: kfreebsd-gnu etc. issues

Robert Millan 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

Re: kfreebsd-gnu etc. issues

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 ke

Re: kfreebsd-gnu etc. issues

2011/1/1 Joseph S. Myers : > [...] 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. F

Re: kfreebsd-gnu etc. issues

2011/1/12 Joseph S. Myers : > 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 rea

Re: kfreebsd-gnu etc. issues

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.

Re: kfreebsd-gnu etc. issues

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?

Re: kfreebsd-gnu etc. issues

Hi Joseph, 2011/1/1 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. >

kfreebsd-gnu etc. issues

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. is the initial patch in this ser