From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19725 invoked by alias); 20 May 2012 21:25:05 -0000 Received: (qmail 19635 invoked by uid 22791); 20 May 2012 21:25:02 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-qa0-f41.google.com (HELO mail-qa0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 May 2012 21:24:48 +0000 Received: by qabg27 with SMTP id g27so1325459qab.0 for ; Sun, 20 May 2012 14:24:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.102.73 with SMTP id f9mr9346230qco.103.1337549086836; Sun, 20 May 2012 14:24:46 -0700 (PDT) Received: by 10.229.169.130 with HTTP; Sun, 20 May 2012 14:24:46 -0700 (PDT) In-Reply-To: <201205202043.q4KKhRGw022215@glazunov.sibelius.xs4all.nl> References: <20120511181737.GP29339@adacore.com> <201205202043.q4KKhRGw022215@glazunov.sibelius.xs4all.nl> Date: Sun, 20 May 2012 21:25:00 -0000 Message-ID: Subject: Re: Three weeks to branching (gdb 7.5 release) From: "H.J. Lu" To: Mark Kettenis Cc: brobecker@adacore.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00753.txt.bz2 On Sun, May 20, 2012 at 1:43 PM, Mark Kettenis wr= ote: >> Date: Sun, 20 May 2012 08:40:26 -0700 >> From: "H.J. Lu" >> >> On Fri, May 11, 2012 at 11:43 AM, H.J. Lu wrote: >> > On Fri, May 11, 2012 at 11:17 AM, Joel Brobecker wrote: >> >> Hello, >> >> >> >> Just a quick heads up: The current tentative date for branching >> >> GDB (7.5 release) is Mon Jun 4th, which is a little over three weeks >> >> away. >> >> >> >> I've created a wiki page for known issues that need to be fixed >> >> before then: >> >> >> >> =A0 =A0http://sourceware.org/gdb/wiki/GDB_7.5_Release >> >> >> >> When you add an issue, please make sure you add a name so we know >> >> who is coordinating the effort. =A0If you don't know who can work >> >> on it, please just post the issue here, and we'll try to find some >> >> help. >> >> >> >> I only know of one issue, which is a noticeable performance degradati= on >> >> that was reported a while ago: >> >> >> > >> > I'd like to merge x32 into GDB 7.5. =A0My x32 change is on hjl/x32/mas= ter >> > branch at >> > >> > http://sourceware.org/git/?p=3Dgdb.git;a=3Dsummary >> > >> > The current diff only has 864 lines. =A0One patch: >> > >> > http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html >> > >> > isn't reviewed yet. =A0I will open a meta bug for x32 integration. >> > >> >> I opened: >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=3D14099 >> >> Thanks for help from everyone. =A0The full GDBserver x32 support >> as well as partial GDB x32 support have been checked in. =A0The >> remaining patches are: >> >> http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html >> http://sourceware.org/ml/gdb-patches/2012-04/msg00191.html >> http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html >> http://sourceware.org/ml/gdb-patches/2012-05/msg00531.html >> http://sourceware.org/ml/gdb-patches/2012-05/msg00533.html >> http://sourceware.org/ml/gdb-patches/2012-05/msg00489.html >> http://sourceware.org/ml/gdb-patches/2012-05/msg00438.html >> http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html >> >> I would appreciate help to get them reviewed and approved. > > As I wrote before, I don't think adding lots if if-statements is the > proper way to add a new ABI to GDB. =A0The proper way is to do it like > the diff below. =A0In that diff, I'm not entirely confident that calling > amd64_linux_init_abi() from amd64_x32_linux_init_abi() makes all that > much sense. =A0For example the amd64_linux_record_tdep stuff probably > isn't right for the x32 ABI. =A0But at least this will give us a > starting point where we won't end up adding > > =A0if (gdbarch_ptr_bit (gdbarch) =3D=3D 32) > =A0 =A0{ > =A0 =A0 =A0... > =A0 =A0} Please take a look at http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html It doesn't add any (gdbarch_ptr_bit (gdbarch) =3D=3D 32). It just changes it to bits_per_word. I add one "gdbarch_ptr_bit (gdbarch) =3D=3D 32" in amd64_linux_sigtramp_start and I will remove them from http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html > =A0else > =A0 =A0{ > =A0 =A0} > > blocks all over the place. > > > > Index: amd64-linux-tdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v > retrieving revision 1.50 > diff -u -p -r1.50 amd64-linux-tdep.c > --- amd64-linux-tdep.c =A012 May 2012 08:54:03 -0000 =A0 =A0 =A01.50 > +++ amd64-linux-tdep.c =A020 May 2012 20:31:53 -0000 > @@ -1543,6 +1543,24 @@ amd64_linux_init_abi (struct gdbarch_inf > > =A0 tdep->i386_syscall_record =3D amd64_linux_syscall_record; > =A0} > + > +static void > +amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbar= ch) > +{ > + =A0struct gdbarch_tdep *tdep =3D gdbarch_tdep (gdbarch); > + =A0const struct target_desc *tdesc =3D info.target_desc; > + > + =A0amd64_linux_init_abi (info, gdbarch); > + =A0amd64_x32_init_abi (info, gdbarch); > + > + =A0if (! tdesc_has_registers (tdesc)) > + =A0 =A0tdesc =3D tdesc_amd64_linux; I assume you meant tdesc_x32_linux here. The problem is when we reach here, if (! tdesc_has_registers (tdesc)) will always be false since tdep->tdesc has been set by amd64_linux_init_abi. > + =A0tdep->tdesc =3D tdesc; > + > + =A0/* GNU/Linux uses SVR4-style shared libraries. =A0*/ > + =A0set_solib_svr4_fetch_link_map_offsets > + =A0 =A0(gdbarch, svr4_ilp32_fetch_link_map_offsets); > +} > > > =A0/* Provide a prototype to silence -Wmissing-prototypes. =A0*/ > @@ -1553,6 +1571,8 @@ _initialize_amd64_linux_tdep (void) > =A0{ > =A0 gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GDB_OSABI_LINUX, amd64= _linux_init_abi); > + =A0gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GDB_OSABI_LINUX, amd64_= x32_linux_init_abi); > > =A0 /* Initialize the Linux target description. =A0*/ > =A0 initialize_tdesc_amd64_linux (); > Index: amd64-tdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /cvs/src/src/gdb/amd64-tdep.c,v > retrieving revision 1.104 > diff -u -p -r1.104 amd64-tdep.c > --- amd64-tdep.c =A0 =A0 =A0 =A014 May 2012 18:56:40 -0000 =A0 =A0 =A01.1= 04 > +++ amd64-tdep.c =A0 =A0 =A0 =A020 May 2012 20:31:54 -0000 > @@ -258,7 +258,8 @@ static const char *amd64_word_names[] =3D > =A0static const char *amd64_dword_names[] =3D > =A0{ > =A0 "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp", > - =A0"r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d" > + =A0"r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d", > + =A0"eip" > =A0}; > > =A0/* Return the name of register REGNUM. =A0*/ > @@ -2729,6 +2730,43 @@ amd64_init_abi (struct gdbarch_info info > =A0 set_gdbarch_stap_parse_special_token (gdbarch, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0i386_stap_parse_special_token); > =A0} > + > + > +static struct type * > +amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum) > +{ > + =A0struct gdbarch_tdep *tdep =3D gdbarch_tdep (gdbarch); > + > + =A0switch (regnum - tdep->eax_regnum) > + =A0 =A0{ > + =A0 =A0case AMD64_RBP_REGNUM: =A0 =A0 /* %ebp */ > + =A0 =A0case AMD64_RSP_REGNUM: =A0 =A0 /* %esp */ > + =A0 =A0 =A0return builtin_type (gdbarch)->builtin_data_ptr; > + =A0 =A0case AMD64_RIP_REGNUM: =A0 =A0 /* %eip */ > + =A0 =A0 =A0return builtin_type (gdbarch)->builtin_func_ptr; > + =A0 =A0} > + > + =A0return i386_pseudo_register_type (gdbarch, regnum); > +} > + > +void > +amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) > +{ > + =A0struct gdbarch_tdep *tdep =3D gdbarch_tdep (gdbarch); > + =A0const struct target_desc *tdesc =3D info.target_desc; > + > + =A0amd64_init_abi (info, gdbarch); > + > + =A0if (! tdesc_has_registers (tdesc)) > + =A0 =A0tdesc =3D tdesc_x32; Again, " if (! tdesc_has_registers (tdesc))" will always false since tdep->tdesc has been set in amd64_init_abi. How do we solve it? My suggestion is to add a new function which is similar to amd64_init_abi, but takes a new argument, const struct target_desc *, as the default tdesc. Both amd64_init_abi and amd64_x32_init_abi will call this function. Will it work for you? Thanks. --=20 H.J.