Re: procfs patches for Linux

Re: procfs patches for Linux

[H.J. Lu]

> 
> 
> As I understand it, a.out versus ELF is not the issue.  As Mike
> explained it to me, the procfs support is at least somewhat separate
> from the a.out/ELF issue.
> 
> The problem is whether the ELF support can be compiled.  With this
> change, anyone who wants to build the gas snapshots targeted for any ELF
> configuration -- be it i386-linux or powerpc-elf or sparc-solaris or
> anything else -- has to have your latest software, only a few days old.
> 
> Because of the way BFD is set up, core file support is compiled in even
> for cross configurations.  (This is a bug, and I'll happily take patches
> to fix it.)  So the Linux core file support has to compile, because

Will you? Please take a look at below.

> people may be using Linux as a development system for a cross-assembler.


That was what I faced more than 2 years ago while bootstrapping
gcc for Linux in a cross-compile environment. One solution is:

# cd bfd
# mdkir targets
# cd targets

We move all the target stuff from bfd/hosts to bfd/targets. In
bfd/configure, we do:

2. if [ -f $srcdir/targets/target.h ]; then
	link $srcdir/targets/target.h to tsysdep.h.
	link $srcdir/hosts/host.h to hsysdep.h.
	echo include "hsysdep.h" > sysdep.h
	echo include "tsysdep.h" >> sysdep.h
   else
	link $srcdir/hosts/host.h to sysdep.h.
   fi

> 
> I'm not entirely convinced that the switch to ELF as the default for gcc
> and binutils won't screw some of those people, where version numbers
> aren't factored into it in any way.  Have you gotten into the FSF's gcc
> documentation (and, ideally, into the release announcement too) some
> notes about using "linuxaout" if people have older Linux systems?  Or do

Yes. I changed install.texi for gcc. But again, I am not sure if
they will read it.

> you just assume everyone always wants the latest development code,
> stability be damned?
> 
> I'm disabling HAVE_PROCFS for Linux in BFD for now, until you can give
> me something that supports both system environments, with sys/procfs.h
> and without.
> 

I will fix it on the linux side. How about my suggestion to
bfd?

BTW, do you need a patch for elf32.em to fix the -Lxxxx bug?


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: procfs patches for Linux

[Ken Raeburn]

   > Because of the way BFD is set up, core file support is compiled in even
   > for cross configurations.  (This is a bug, and I'll happily take patches
   > to fix it.)  So the Linux core file support has to compile, because

   Will you? Please take a look at below.

   > people may be using Linux as a development system for a cross-assembler.


   That was what I faced more than 2 years ago while bootstrapping
   gcc for Linux in a cross-compile environment. One solution is:

   # cd bfd
   # mdkir targets
   # cd targets

   We move all the target stuff from bfd/hosts to bfd/targets. In
   bfd/configure, we do:

   2. if [ -f $srcdir/targets/target.h ]; then
	   link $srcdir/targets/target.h to tsysdep.h.
	   link $srcdir/hosts/host.h to hsysdep.h.
	   echo include "hsysdep.h" > sysdep.h
	   echo include "tsysdep.h" >> sysdep.h
      else
	   link $srcdir/hosts/host.h to sysdep.h.
      fi

The core file support is often dependent on system header files that
we don't duplicate in the binutils distribution.  Trying to include
sunos header files when building a sunos cross-assembler hosted on
linux won't work because you don't have the sunos header files.  And
you shouldn't have to copy them all over from one system to the other
just to build binutils.

In a cross configuration, it generally shouldn't be built.  There may
be cases where we do have enough information to do it, I don't know.
But I don't think that's going to be the common case.  (Currently I
don't think cross-debuggers are expected to handle core files, so it'd
be no real loss to omit the core file support altogether in cross
configurations.)

   > I'm disabling HAVE_PROCFS for Linux in BFD for now, until you can give
   > me something that supports both system environments, with sys/procfs.h
   > and without.

   I will fix it on the linux side.

Thanks.

   BTW, do you need a patch for elf32.em to fix the -Lxxxx bug?

Maybe.  I want to check it against the behavior on Solaris or some
other non-GNU ELF system.

Re: procfs patches for Linux

[H.J. Lu]

>    gcc for Linux in a cross-compile environment. One solution is:
> 
>    # cd bfd
>    # mdkir targets
>    # cd targets
> 
>    We move all the target stuff from bfd/hosts to bfd/targets. In
>    bfd/configure, we do:
> 
>    2. if [ -f $srcdir/targets/target.h ]; then

Change that to

	if [ $default_target == $host and 
		-f $srcdir/targets/default_target.h ]; then

> 	   link $srcdir/targets/target.h to tsysdep.h.
> 	   link $srcdir/hosts/host.h to hsysdep.h.
> 	   echo include "hsysdep.h" > sysdep.h
> 	   echo include "tsysdep.h" >> sysdep.h
>       else
> 	   link $srcdir/hosts/host.h to sysdep.h.
>       fi
> 
> The core file support is often dependent on system header files that
> we don't duplicate in the binutils distribution.  Trying to include
> sunos header files when building a sunos cross-assembler hosted on
> linux won't work because you don't have the sunos header files.  And
> you shouldn't have to copy them all over from one system to the other
> just to build binutils.
> 
> In a cross configuration, it generally shouldn't be built.  There may
> be cases where we do have enough information to do it, I don't know.
> But I don't think that's going to be the common case.  (Currently I
> don't think cross-debuggers are expected to handle core files, so it'd
> be no real loss to omit the core file support altogether in cross
> configurations.)

How about my changes above?

> 
>    BTW, do you need a patch for elf32.em to fix the -Lxxxx bug?
> 
> Maybe.  I want to check it against the behavior on Solaris or some
> other non-GNU ELF system.
> 

I already checked SVR4.2. It doesn't have the GNU ld bug.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com