Re: Xtensa port, part 2: config.gcc and new config/xtensa files

[Richard Henderson <rth at redhat dot com>]

On Mon, Dec 03, 2001 at 04:24:30PM -0800, Bob Wilson wrote:
> OK.  I knew I had to do this for 3.1 anyway.  I guess I might as well do 
> it for the 3.0 version as well....

Err.. just so you know, I was reviewing this for 3.1, not 3.0.
I suspect that Mark won't take new ports for 3.0.3 at this point,
and I would be surprised if there's a 3.0.4.  In either case,
you'd need his ok for it to go onto the release branch.

> >>+ void
> >>+ abort_with_insn (insn, reason)
> >>
> > 
> > Eh?
> 
> I'm not sure what you mean here.  I copied this function from the MIPS 
> port.  Is there some reason why it shouldn't be used?

I'll interpret "it" loosely.  The mips port is not the best place to
go for examples.  It's older, and it suffered for a few years without
a maintainer.

Besides, there's

toplev.h:#define fatal_insn(msgid, insn)
toplev.h:#define fatal_insn_not_found(insn)

and several other similar diagnostic routines already defined.

> It isn't emitted by the prologue expander.  The only way that I could 
> find to make this work without adding new hooks into GCC was to emit the 
> "unspec_volatile" as a side effect of copying the incoming argument in 
> a7 (the hard frame pointer register) to a pseudo.  I could look at the 
> number and types of the incoming arguments to determine if there is an 
> argument in a7 but I'd still have to find the "unspec_volatile" insn 
> since I need to transform all the instructions prior to that point. 
> It's a lot easier to just search for it.

Oh lord.  I'll reiterate what I may have mentioned before in 
another thread -- I think it's a big mistake to define an ABI
that passes arguments in the hard frame pointer -- but let it
go for now.



r~