Re: [m68k] return values

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Mon, 19 Jun 2006 16:28:47 +0100
> From: Nathan Sidwell <nathan@codesourcery.com>
> 
> Mark Kettenis wrote:
> 
> > Well, I fear you've managed to confuse yourself.  The current m68k
> > default target uses m68k_extract_return_value(), which reads all
> > return values from %d0.
> 
> you're right.  ok, the whole problem I'm trying to solve is to get
> the function return working for m68k-elf.  That appears to be a
> mixture of original and svr4 features.  Namely:
> 
> a) returns always go in %d0 (original)
> b) small structures can be passed in registers (svr4)
> c) structure return values use the struct_return convention (svr4?)
> 
> What approach do you think would be best in tackling this?  The way
> I'd gone at it was to treat the m68k-elf as a variant of svr4
> (i.e. #a was the exceptional behaviour).  It would be possible to
> organize it as original ABI, but with #b & #c as the exceptions.

Well, #b basically means reg_struct_return convention, which already
is the default.  And with #c you probably mean that the caller
allocates the memory to store the returned structure instead of having
the callee provide it in a static buffer (which is braindead since it
is non-reentrant).  The current code should cater for both, as long as
a pointer to the memory is returned in %d0.  Note that for SVR4 the
pointer is returned in %a0, but that makes no sense for m68k-elf since
normal pointers are returned in %d0.  So I believe that the default
m68k gdbarch vector should work just fine for m68k-elf.  But perhaps
it is a good idea to verify that the value is indeed returned in %d0.

> Do you think the default should be compatible with m68k-elf, or
> should the user explicitly set the abi in that case?

I believe the default gdbarch vector should be suitable for m68k-aout,
m68k-coff and m68k-elf.

> As you may be aware, #b is implemented by GCC in a horrible way that
> is dependent on internal implementation details -- it's not just
> that the structure is 'small' or even 2^n bytes.  I have a patch
> that emulate's GCC's behaviour, and I was going to post that after
> this patch was resolved.

And unfortunately GCC's implementation is almost a guaranteed to break
the ABI every now and then.  So it wouldn't surprise me at all if your
GCC is broken; or at least different from the GCC that comes with the
latest OpenBSD/mac68k release, which still uses GCC 2.95.3.  So it may
actually be impossible to solve this.  Fortunately you're probably
fixing corner cases in what is already a corner case; structures tend
to be larger than 8 bytes.

Could you send me the testsuite output for your m68k-elf target?  I'll
run the testsuite on my Quadra 800 tonight so we can compare results.

Mark