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: Is -T meaningful as an assembler option?


Sandra Loosemore wrote:

I'm willing to prepare a patch that removes %{T} from all ASM_SPECs and documents -T as a linker option, but....

(a) is this the right thing to do?
(b) is this appropriate to submit for stage 3?

Following up on my own message, I'm now inclined to think the answer to both questions is "no". :-(


I've done some more investigation this afternoon. It appears this bit of ASM_SPECs came into being in config/svr4.h in gcc 2.0, along with a LINK_SPEC that did *not* include -T. (OTOH, the use of -T as a linker flag in the generic code predates this, and was already present in gcc-1.42.) The comments in the file were pretty much what they are now, indicating that it's trying to pass through all the useful options for the native SVR4 assembler and linker. From there, the ASM_SPEC seems to have been copied around to other target-specific .h files, including the config/rs6000/sysv4.h that's being picked up by the powerpc-eabi config.

I have no idea what -T means as a flag for the System V "as" command, and whether there are other targets that really do use the native System V assembler. But assuming a System V assembler, instead of gas, seems silly for powerpc-eabi and powerpc-linux, at least. And both of those configs simultaneously think -T is a linker option, too. :-P

To make a long story short, it looks like a bigger fix is required here than just hacking up the ASM_SPEC strings -- probably some global default spec to use when the assembler is gas and some reorganization of configs for lots of targets not to override that default except when there's very good reason to assume some other assembler. (E.g., why should the powerpc-eabi target be sucking in configuration bits specific to System V, anyway?) This looks like a big task, with lots of target-specific hackery and testing required.

Anyone else have any comments or other ideas about how to proceed?

-Sandra


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