Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb@sources.redhat.com
Subject: Re: m68k structure return register
Date: Wed, 19 Sep 2007 12:46:00 -0000	[thread overview]
Message-ID: <200709191224.28030.vladimir@codesourcery.com> (raw)
In-Reply-To: <200706201325.07067.vladimir@codesourcery.com>

On Wednesday 20 June 2007 13:25:06 Vladimir Prus wrote:

Does anybody object to the course of action I've proposed
in the below email? If not, I'll send a patch.

- Volodya

> Hello,
> it appears that the way gdb expects code to
> return structure values on m68k is not exactly
> consistent with how gcc actually passes them.
> 
> Basically, for function returning structures,
> caller should pass an address of memory where
> structure should be returned, using either register a0,
> or register a1. Which register is used for what target
> is precisely where confusion lies.
> 
> In gcc/config/m68k there are three definitions:
> 
> m68k.h:#define M68K_STRUCT_VALUE_REGNUM A1_REG
> m68kelf.h:#define M68K_STRUCT_VALUE_REGNUM A0_REG
> netbsd-elf.h:#define M68K_STRUCT_VALUE_REGNUM A0_REG
> 
> This, together with config.gcc, gives me the following table
> of what register is used for what target.
> 
>         1. m68k-*-aout*                                 a1
>         2. m68k-*-coff*                                 a1
>         3. m68k-*-elf*                                  a0
>         4. m68k*-*-netbsdelf*                           a0
>         5. m68k*-*-openbsd*                             a1
>         6. m68k-*-uclinuxoldabi*                        a0
>         7. m68k-*-uclinux*                              a1
>         8. m68k-*-linux*                                a1
>         9. m68k-*-rtems*                                a0
> 
> Here's a breakdown of how those targets map to gdb's .mt files in
> config/m68k:
> 
> Group I -- monitor.mt -- just m68k-tdep.c
> 
>         1. m68k-*-aout*                                 a1
>         2. m68k-*-coff*                                 a1
>         3. m68k-*-elf*                                  a0
>         6. m68k-*-uclinuxoldabi*                        a0
>         7. m68k-*-uclinux*                              a1
>         9. m68k-*-rtems*                                a0
> 
> In gdb, all target here use the register set in m68k_gdbarch_init -- 
> currently A1, which register is wrong for half of targets. I'll get to this
> group shortly.
> 
> Group II -- nbsd.mt/obsd.mt -- m68k-tdep.c + m68kbsd-tdep.c
> 
>         4. m68k*-*-netbsdelf*                           a0
>         5. m68k*-*-openbsd*                             a1
>         
> In this group. netbsd has osabi sniffer that sets a0. openbsd
> just gets whatever  m68k_gdbarch_init sets -- currently a1.
> 
> Group III -- linux.mt -- m68k-tdep.c + m68klinux-tdep.c
> 
>         8. m68k-*-linux*                                a1
> 
> Here, there's osabi sniffer that causes a1 to be used.
> 
> The problem is therefore, group I. Notably, for m68k-elf gcc uses
> a0, whereas gdb assumes a1. And for m68k-elf, we cannot set
> any osabi sniffer. I think that nowdays m68k-elf is probably the most
> important target in that group.
> 
> I would suggest the following:
> 
> 1. Change gdb's default to use a0 register, so that bare-metal works.
> 2. If possible, add osabi sniffers to uclinux, openbsdb and rtems, that
> will cause gdb to use a1. 
> 
> Does this sound reasonable, and if so, anybody knows how I can
> implement osabi sniffers listed in (2)? I've being told osabi sniffer for
> uclinux might be impossible, and I don't know much about either openbsd
> or rtems.
> 
> Thanks,
> Volodya


  reply	other threads:[~2007-09-19  8:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-20  9:25 Vladimir Prus
2007-09-19 12:46 ` Vladimir Prus [this message]
2007-09-19 14:06   ` Daniel Jacobowitz
2007-09-20  9:06     ` Ralf Corsepius
2007-09-30 20:40     ` Vladimir Prus
     [not found]       ` <20070930204008.GA15765@caradoc.them.org>
2007-10-05 12:31         ` Vladimir Prus
2007-10-05 20:36           ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200709191224.28030.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox