i960 egcs 970901 problem

i960 egcs 970901 problem

[Joel Sherrill]

There is no default setting of SUBTARGET_SWITCHES in config/i960/i960.h.

--joel

Wed Sep  3 16:23:24 CDT 1997  Joel Sherrill (joel@OARcorp.com)

	* i960/i960.h: Added default for SUBTARGET_SWITCHES macro.

*** /tmp/i960.h	Wed Sep  3 16:20:35 1997
--- i960.h	Wed Sep  3 16:19:43 1997
***************
*** 272,277 ****
--- 272,280 ----
      SUBTARGET_SWITCHES                                                  \
      { "", TARGET_DEFAULT}}
  
+ /* This are meant to be redefined in the host dependent files */
+ #define SUBTARGET_SWITCHES
+ 
  /* Override conflicting target switch options.
     Doesn't actually detect if more than one -mARCH option is given, but
     does handle the case of two blatantly conflicting -mARCH options.  */

Re: i960 egcs 970901 problem

[Stephen Williams]

	* i960/i960.h: Added default for SUBTARGET_SWITCHES macro.

I've seen you mention the subtarget switches and -qNAME several times
now, but I don't know what they are. They look like something I want to
know about. Are these things described anywhere?

-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: i960 egcs 970901 problem

[Joel Sherrill]

On Wed, 3 Sep 1997, Stephen Williams wrote:

> 	* i960/i960.h: Added default for SUBTARGET_SWITCHES macro.
> 
> I've seen you mention the subtarget switches and -qNAME several times
> now, but I don't know what they are. They look like something I want to
> know about. Are these things described anywhere?

AFAIK there is no formal user documentation on them right now.  I have
picked the brains of Michael Meissner and Rob Savoye to get my specs
extensions working.  I felt guilty everytime I emailed them for help but I
did and still do appreciate it.

The idea is that you can have a user defined extensions to the specs file. 
RTEMS uses this to allow per-board information to be passed to each
invocation of gcc without requiring this information to be merged into gcc
distributions.  As there are lots of boards (RTEMS has suport for > 20),
many embedded baords are proprietary, and merging this into gcc is too
complex for what you really want to do, the specs file way is nice.  

For RTEMS, we invoke gcc with this set of arguments:

   -B<BOARD_SPECIFIC_DIRECTORY> -specs bsp_specs -qrtems

Then each board support package (BSP) provides a bsp_specs file like this
one:

%rename cpp old_cpp
%rename lib old_lib
%rename endfile old_endfile
%rename startfile old_startfile
%rename link old_link

*cpp:
%(old_cpp) %{qrtems: -D__embedded__} -Asystem(embedded)

*lib:
%{!qrtems: %(old_lib)} %{qrtems: --start-group -lc -lrtemsall -lgcc
--end-group}

*startfile: 
%{!qrtems: %(old_startfile)} %{qrtems: start.o%s}

*link:
%{!qrtems: %(old_link)} %{qrtems: -dc -dp -N -T linkcmds%s -e start}


There must be a blank line at the end of the bsp_specs file.  Also each
rule line must be on a single line.  Violating either gives some ugly
errors.  

The above one is not all that interesting but you can see the idea.  

The example Michael Meissner sent me provided for multiple "BOARD" options
in a single specs extensions file.

The -specs option was added past gcc 2.7.2.x.

This is cursory but might be a useful start for something in the manual.
Figuring this out from the description of each specs was too tough for me.

--joel

Re: i960 egcs 970901 problem

[Jeffrey A Law]

  In message < Pine.BSF.3.96.970903162048.188A-100000@vespucci.advicom.net >you write:
  > Wed Sep  3 16:23:24 CDT 1997  Joel Sherrill (joel@OARcorp.com)
  > 
  > 	* i960/i960.h: Added default for SUBTARGET_SWITCHES macro.
Thanks.  I've install this patch.

jeff

Re: i960 egcs 970901 problem

[Stephen Williams]

joel@OARcorp.com said:
> The idea is that you can have a user defined extensions to the specs 
> file.  RTEMS uses this to allow per-board information to be passed to 
> each invocation of gcc without requiring this information to be 
> merged into gcc distributions.

I guessed it was something along these lines, thank you and Michael for
answering. I still think I need to have uCR support patched into gcc for
my work (i.e. --target=i960-ucr) but things like start files and linker
scripts are a PERFECT use of this haquerie.

I fussed with the -specs option before, but I was missing the bit of
detail about needing the blank line at the end. I was also missing the
%rename magic that really makes things look slick.
-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: i960 egcs 970901 problem

[Joel Sherrill]

On Thu, 4 Sep 1997, Stephen Williams wrote:

> I guessed it was something along these lines, thank you and Michael for
> answering. I still think I need to have uCR support patched into gcc for
> my work (i.e. --target=i960-ucr) but things like start files and linker
> scripts are a PERFECT use of this haquerie.

I am in the same boat.  I have about 9 CPU-rtems targets in gcc, binutils,
etc but they are very minimal.  Just enough to get a toolset built with
the object format I think that CPU family should use embedded and -Drtems.
:)

Each board does its magic with -specs.

> I fussed with the -specs option before, but I was missing the bit of
> detail about needing the blank line at the end. I was also missing the
> %rename magic that really makes things look slick.

Same here.  And it was not very pretty. :)

-joel

Re: i960 egcs 970901 problem

[meissner]

| > I fussed with the -specs option before, but I was missing the bit of
| > detail about needing the blank line at the end. I was also missing the
| > %rename magic that really makes things look slick.
| 
| Same here.  And it was not very pretty. :)

Feel free to submit patches to get right of the blank line at the bottem
kludge.  I'm kind of busy right now to do it myself right now.

Re: i960 egcs 970901 problem

[meissner]

| 	* i960/i960.h: Added default for SUBTARGET_SWITCHES macro.
| 
| I've seen you mention the subtarget switches and -qNAME several times
| now, but I don't know what they are. They look like something I want to
| know about. Are these things described anywhere?

What Joel is doing is using the new -specs <file> option that I wrote to add
extra switches without modifing the base compiler.  In the embedded world, you
often times have lots of differeent boards that have differences that you
encapsulate in a library, etc.  You don't necessarily want to modify the
compiler to add new -m options (for instance the board may be unique to a
particular user site).

The -q<option> is currently being used because GCC doesn't use a switch
beginning with -q.  I eventually want to add a way that you could use the more
natural -m<option> and strip out certain options from being passed on the cc1.

The specs language is documented in the large comment in gcc.c.  At some point,
this should go in the regular documentation.

To give a more concrete example, if I had not added either -myellowknife or
-mads to the PowerPC, the same functionality could have been added for
-qyellowknife or -qads, by putting the following into a file and using
-specs <file> (note, due to the way specs are currently parsed, there must be
one blank line at the end of the file, also each of the lines must be one
physical line):

%rename cpp old_cpp
%rename lib old_lib
%rename endfile old_endfile
%rename startfile old_startfile
%rename link old_link

*cpp:
%(old_cpp) %{qads: -D__ADS__} %{qyellowknife: -D__YELLOWKNIFE__}

*lib:
%{!qyellowknife: %{!qads: %(old_lib)}} %{qads: --start-group -lads -lc --end-group} %{qyellowknife: --start-group -lyk -lc --end-group}

*endfile:
%{!qyellowknife: %{!qads: %(old_endfile)}} %{qads: ecrtn.o%s} %{qyellowknife: ecrtn.o%s}

*startfile:
%{!qyellowknife: %{!qads: %(old_startfile)}} %{qads: ecrti.o%s crt0.o%s} %{qyellowknife: ecrti.o%s crt0.o%s}

*link:
%{!qyellowknife: %{!qads: %(old_link)}} %{qads: -T ads.ld%s} %{qyellowknife: -T yellowknife.ld%s}

--
Michael Meissner, Cygnus Solutions (East Coast)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)