This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [m68k] return values
> 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