This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 9 Jun 2012 07:30:24 -0700
- Subject: Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
- References: <20120511181737.GP29339@adacore.com> <CAMe9rOqWL5JybaZskQH0M+BELAuEAtLRbEJxxb9qTn34LvhcGw@mail.gmail.com> <CAMe9rOo85pyK3YLJ_jLzqn+4NAd7RZpup7KOn0eAmB4sXda=+A@mail.gmail.com> <201205202043.q4KKhRGw022215@glazunov.sibelius.xs4all.nl> <CAMe9rOojkLGHcQ3KPn=NmNg+y+jPnL-eB67TL2+xgVUaOftHNQ@mail.gmail.com> <201205202138.q4KLcWBf011913@glazunov.sibelius.xs4all.nl> <CAMe9rOqmWwEjR88sZYynaHQ9-yv3TDQG3a7=9DaXwLKcoWo_gw@mail.gmail.com> <201205282026.q4SKQ737007589@glazunov.sibelius.xs4all.nl> <CAMe9rOoQm1eh4u+t5F-gGzyB9bqwLo4h7S=VNP4BPZXSu9RZCA@mail.gmail.com> <CAMe9rOp1Z7kQb3PzYMnCU1QurNgS+zHxf=RryyUTbk6R3SsdMQ@mail.gmail.com> <CAMe9rOq-Vg_NWUR=z3Q6-wv71TMZUYiQ6K+XWiBqZh1TiA_Bvw@mail.gmail.com> <201206051316.q55DGSq4017712@glazunov.sibelius.xs4all.nl>
On Tue, Jun 5, 2012 at 6:16 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> 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.
Hi Mark,
Have you got time to review my change?
Thanks.
--
H.J.