Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: hjl.tools@gmail.com
Cc: gdb-patches@sourceware.org
Subject: Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
Date: Tue, 05 Jun 2012 13:16:00 -0000	[thread overview]
Message-ID: <201206051316.q55DGSq4017712@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <CAMe9rOq-Vg_NWUR=z3Q6-wv71TMZUYiQ6K+XWiBqZh1TiA_Bvw@mail.gmail.com>	(hjl.tools@gmail.com)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

> Date: Tue, 5 Jun 2012 05:58:18 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> 
> On Thu, May 31, 2012 at 11:18 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > On Mon, May 28, 2012 at 2:18 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> >> On Mon, May 28, 2012 at 1:26 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >>>> Date: Sun, 20 May 2012 15:48:54 -0700
> >>>> From: "H.J. Lu" <hjl.tools@gmail.com>
> >>>>
> >>>> Does this one look OK.  I extracted x32_init_abi from amd64_x32_init_abi
> >>>> since amd64_x32_linux_init_abi can't call amd64_init_abi after
> >>>> calling amd64_linux_init_abi.
> >>>
> >>> I guess multiple-inheritance is a bad idea, even when implemented in C ;)
> >>>
> >>> I really do think that amd64_x32_linux_init_abi() should call
> >>> amd64_x32_init_abi().  That way it is immediately obvious that the OS-specific ABI inherits everything from the generic ABI.
> >>
> >> X32 kernel interface are highly OS specific.  Different OSes can implement
> >> very different kernel interfaces.  The only generic x32 bits are
> >>
> >>  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> >>
> >>  tdep->num_dword_regs = 17;
> >>
> >>  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
> >>
> >>  set_gdbarch_long_bit (gdbarch, 32);
> >>  set_gdbarch_ptr_bit (gdbarch, 32);
> >>
> >> They are the same for all x32 OSes since they are determined by
> >> hardware, not OS.
> >>
> >>> In order too avoid too much code duplication, the common bits should
> >>> be split out from amd64_linux_init_abi() into a seperate function that
> >>> gets called from both amd64_linux_init_abi() and
> >>> amd64_x32_linux_init_abi().  As I wrote earlier, it isn't entirely
> >>> obvious that everything in amd64_linix_init_abi() applies to the x32
> >>> ABI.  So we should be conservative in moving stuff into the common
> >>> function.  In fact it might be a good idea to start out with something
> >>> like the attached diff, and gradually move things over.
> >>
> >> Linux x32 kernel interface shares > 90% of Linux amd64 kernel
> >> interface (309 system calls out of 337 are the same).  See
> >> 64-bit system call table in Linux kernel 3.4:
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=arch/x86/syscalls/syscall_64.tbl;h=dd29a9ea27c560a9d2fcb6e1c2983f8b8e9be407;hb=HEAD
> >>
> >> I believe we should start with sharing everything between Linux/x32
> >> and Linux/amd64.  We can update x32 part as we go.
> >>
> >
> >
> > Here is the updated patch.  I added amd64_x32_init for generic x32
> > setting.  It can be used by all x32 init_abi functions.  Since
> > tdep->tdesc can't be changed after being used, I renamed
> > amd64_init_abi/amd64_init_abi to amd64_init/amd64_linux_init
> > to take an  argument to set tdep->tdesc properly.  OK for trunk?
> >
> > Thanks.
> >
> 
> Hi Mark,
> 
> Do you have a chance to take a look at this?

Sorry, no.  Unliekly to be able to look at it until Thrusday evening.


  reply	other threads:[~2012-06-05 13:16 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-11 18:17 Three weeks to branching (gdb 7.5 release) Joel Brobecker
2012-05-11 18:43 ` H.J. Lu
2012-05-14 14:45   ` Joel Brobecker
2012-05-20 15:40   ` H.J. Lu
2012-05-20 20:44     ` Mark Kettenis
2012-05-20 21:25       ` H.J. Lu
2012-05-20 21:39         ` Mark Kettenis
2012-05-20 22:49           ` H.J. Lu
2012-05-25 16:52             ` H.J. Lu
2012-05-28 20:26             ` x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release)) Mark Kettenis
2012-05-28 21:18               ` H.J. Lu
2012-05-31 18:18                 ` H.J. Lu
2012-06-05 12:58                   ` H.J. Lu
2012-06-05 13:16                     ` Mark Kettenis [this message]
2012-06-09 14:30                       ` H.J. Lu
2012-06-10 21:52                   ` Mark Kettenis
2012-06-11 13:42                     ` H.J. Lu
2012-06-12 21:23                       ` Mark Kettenis
2012-06-13 20:29                         ` x32 ABI Support (committed) Mark Kettenis
2012-06-13 20:41                           ` Mark Kettenis
2012-05-12 15:26 ` Three weeks to branching (gdb 7.5 release) Doug Evans
2012-05-20 14:59   ` Doug Evans
2012-06-11 15:35     ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
2012-06-11 15:52       ` Doug Evans
2012-06-11 16:00         ` Joel Brobecker
2012-06-21 20:20         ` Joel Brobecker
2012-06-21 20:25           ` Doug Evans
2012-06-22 14:47           ` Jan Kratochvil
2012-06-22 16:32             ` Joel Brobecker
2012-06-22 16:41               ` Jan Kratochvil
2012-06-22 17:38                 ` Branching time + 1 week Tom Tromey
2012-06-22 20:31                 ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
2012-06-24  9:14                   ` [commit] gnulib update [Re: Branching time + 1 week] Jan Kratochvil
2012-06-22 16:42               ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") H.J. Lu
2012-06-11 15:59       ` H.J. Lu
2012-06-11 16:11         ` Joel Brobecker
2012-06-11 16:20           ` H.J. Lu
2012-05-29 17:17 ` Three weeks to branching (gdb 7.5 release) Jan Kratochvil
2012-05-30 22:04   ` Joel Brobecker
2012-06-07 19:36     ` Maciej W. Rozycki
2012-06-11 14:58       ` Joel Brobecker
2012-06-12 15:39         ` Maciej W. Rozycki

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=201206051316.q55DGSq4017712@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb-patches@sourceware.org \
    --cc=hjl.tools@gmail.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