This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [PATCH] remove arm/unknown-elf.h


> On Thu, Dec 06, 2001 at 02:28:26PM +0000, Richard Earnshaw wrote:
> > > Every consumer of arm/unknown-elf.h immediately includes arm/elf.h (via
> > > tm_files).  There are no consumers of arm/unknown-elf.h only.
> > > Thus arm/unknown-elf.h can be folded into arm/elf.h.
> > 
> > You can't reach this conclusion from your argument; it should be perfectly 
> > possible to create an ELF target that uses elf.h, but doesn't want the 
> > definitions in unknown-elf.h -- that is the guiding decision.
> 
> Lets agree to disagree here -- I prefer to talk about existing reality
> rather than "some day possibilities".  Especially since when that time
> comes it isn't hard to DTRT once it is known.

I'm not trying to argue that the current split between elf.h and 
unkown-elf.h is perfect, but it is a reasonable starting point -- it would 
be wrong to loose that separation, which is what your patch does.

> > unknown-elf.h is supposed to contain the bits of an elf interface that 
> > would normally be set by the OS: in this case there is no OS (it's 
> > unknown).
> 
> Then the file fails miserably at that.  By your arguments it should not
> be used ANYWHERE except for 'arm-unknown-elf'.  Instead it is included by
> every target that DOES have an OS.

Indeed, that's exactly what I would expect (well, xscale-unknown-elf would 
also use it, but that configuration is also somewhat of an anomaly) -- it 
makes no sense to me that this file has been used across a range of real 
OS targets.

> 
> I also find this in unknown-elf.h a bit insulting:
> 
>     #define TARGET_VERSION  fputs (" (ARM/ELF non-Linux)", stderr);
> 
> What is all the world Linux unless otherwise told???  Is arm/elf.h really
> primarily targeting Linux and everyone else should just deal with any
> wrong definitions in it?  How about just "ARM/ELF", or "ARM/ELF generic",
> or "ARM/ELF Embedded"?

Well, I didn't put that in there, so please calm down.

Anyway, as a NetBSD user, I completely agree; in fact, I thought I'd 
already removed that bit of stupidity.

> 
> 
> > It seems bizarre to me that the arm-linux ports are including 
> > this file.
> ...
> > So I don't think your patch is correct.
> 
> Also, since you aren't giving me anything other than "NO"'s in my
> attempts at cleaning up stuff.  Would you please do something about the
> bogus definitions of STARTFILE_SPEC, ENDFILE_SPEC, SUBTARGET_CPP_SPEC,
> PREFERRED_DEBUGGING_TYPE in unknown-elf.h?  Or tell me that
> arm-*-freebsd* can be the first target that includes arm/elf.h w/o
> unknown-elf.h?  

"can" is not strong enough.  I really do not think you should be using 
unknown-elf.h in the freebsd configuration.

> 
> The most affective bits from unknown-elf.h are "ASM_OUTPUT_ALIGNED_BSS"
> and "ASM_OUTPUT_ALIGNED_DECL_LOCAL".  Are these not needed by all(most)
> ELF ARM targets?

Quite possibly; and it is probable that they are in the wrong file 
(without spending more time analysing this than I have spare at the moment 
I can't be sure).

> It is getting very hard to figure out where in the chain of "elfos.h
> arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h" ${fbsd_tm_file} and
> arm/freebsd.h should be placed.

For the moment, I would suggest you put it at the end; then you can 
override anything that is defined elsewhere.  As an alternative, if it 
turns out that you must define something before including one of the other 
headers, then you can probably make some other definitions persist by 
adding wrapping the normal definitions in "#ifndef".

> > It seems to me that the abstractions in GCC for target CPU and OS are 
> > horribly intermixed, and that it would be useful to try and tease these 
> > apart somehow.
> 
> You get zero argument out of me about this.  I'm trying the best I can do
> do something about it.

Sorting out the ARM header files is on my to-do list; it just hasn't 
percolated to the top yet.

Longer term I think I'd like to see defines such CPP_OS_SPEC and 
CPP_CPU_SPEC replacing CPP_SPEC at the top level.  This would provide a 
much more robust separation between OS and CPU.

R.



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