https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379

--- Comment #10 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #9)
> > Uggh - these ancient options in the backend. mapcs-frame is quite ancient
> > and isn't really something that's tested very often, no wonder it's rotting.
> > In this case we seem to have regressed something that worked earlier,
> 
> Yes, indirect tailcalls used to be rejected by the back-end.

Indeed.

> 
> > I do wonder if the fix here is to just turn IP regnum into a fixed register 
> > in
> > the presence of mapcs-frame.
> 
> This would only turn the problem into an ICE here.  

Hmmmm not sure.

> I think this needs to be
> fixed in arm_function_ok_for_sibcall, either in a big-hammer-ish way
> (disable again indirect tailcalls with -mapcs-frame) or in a more precise
> way.

Sure that would work too but it feels like a rather big hammer. In the absence
of anything else, I'm happy to review a patch if someone could post this
upstream and get it tested, I won't have time to work on this bug for the next
week or 2.

While we are here, what's the thought on deprecating mapcs-frame in the
arm-wrs-vxworks community ?  It is not really something that's part of the ABI
(it predates EABI), doesn't work with Thumb2 and not tested regularly and we
keep finding issues with this.

Can arm-wrs-vxworks move to using the EHABI information and unwinding
information from there to handle such backtraces - after all libunwind has the
capability now for unwinding ARM EHABI tables if you needed a generic library
to do this ? 


regards
Ramana

Reply via email to