This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] rs6000.c ELF bits inclusion


On Wed, May 02, 2001 at 11:52:33PM -0400, David Edelsohn wrote:
> 	Isn't this a question of whether config/svr4.h assumes to much?

Well... it used to, but that's why elfos.h was created.  The object
format is named "ELF", not "SVR4" (or "SYSV4").  Thus the generic object
file format specifications were pulled out of config/svr4.h. I(FreeBSD)
am not an AT&T/USL/NOVELL/SCO/CALDERA OS.  I don't follow their file
system layouts, nor their command-line options.  I do share their object
file format.  Ie. the ELF gABI does apply to me and SVR4.

Thus I feel "elfos" is a fine name for the object file bits than "svr4",
but I really don't care what you call it.  As long as there is a
difference between object file bits and system/platform implementation
bits.  `elfos.h' isn't perfect yet, as it still has too much of svr4.h
left in it, but I hope to clean up the CVS conflicts soon in my elfos.h
where I fixed this.  (also there are things in elfos.h that need to be in
<arch>/elf.h, as alpha/elf.h has to undo thing in elfos.h)

It is my strong opinion that every arch should have a config/<arch>/elf.h
header also, to teak things in the applicable ELF psABI.  We have this
for alpha and i386 (although it would be very nice to move
config/i386/i386elf.h to config/i386/elf.h, so that the rule is every ELF
platform includes 
"elfos.h ${platform}.h ${arch}/elf.h ${arch}/${platform}.h".

 
> 	Why is the right solution to change rs6000.c?

In this case, because rs6000.c shouldn't care that it is being compiled
for an AT&T/USL/NOVELL/SCO/CALDERA OS, but rather an ELF binary file
format one.


> maybe it isn't.  To me this is a broader design question than FreeBSD
> relying directly upon elfos.h and sweeping the changes under the rug.

Actually many things include config/svr4.h and then undoes what svr4.h
does.  This is simply because many of the maintainers haven't yet cleaned
up their files.  The gcc/config/ header include spaghetti is still alive
and I untangle it when I discover it and it is easy for me to test that I
have not problem something in the untangle.

 
> 	config/freebsd.h is duplicating pieces of config/svr4.h.

If they are line-for-line duplications, then the bits should be moved to
elfos.h if they are truly generic ELF related.  Otherwise there is no
big deal in this -- FreeBSD sits _beside_ SVR4 as a target.


> Is there no way to separate the
> system-specific pieces of config/svr4.h from the ABI-specific pieces so
> that FreeBSD could shared the latter with other SVR4-based system?

Yes, elfos.h and <arch>/elf.h.  Is there some reason this is not
suffient?

-- 
-- David  (obrien@FreeBSD.org)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]