From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28605 invoked by alias); 13 Dec 2012 10:57:09 -0000 Received: (qmail 28595 invoked by uid 22791); 13 Dec 2012 10:57:08 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Dec 2012 10:57:04 +0000 Received: from md13.u-strasbg.fr (md13.u-strasbg.fr [130.79.200.248]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id qBDAurT7020053 ; Thu, 13 Dec 2012 11:56:53 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms18.u-strasbg.fr [130.79.204.118]) by md13.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id qBDAuqsq014123 ; Thu, 13 Dec 2012 11:56:53 +0100 (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id qBDAuo3N012225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) ; Thu, 13 Dec 2012 11:56:50 +0100 (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Pedro Alves'" Cc: "'asmwarrior'" , "'Joel Brobecker'" , "'Eli Zaretskii'" , References: <20121024194517.GK3555@adacore.com> <011901cdb2ab$48076b90$d81642b0$@muller@ics-cnrs.unistra.fr> <20121105171121.GA2972@adacore.com> <50991f5f.8382440a.1100.ffff82abSMTPIN_ADDED@mx.google.com> <509ABA17.30507@redhat.com> <000301cdbd96$f5cd9f10$e168dd30$@muller@ics-cnrs.unistra.fr> <20121122173019.GF9964@adacore.com> <15690.5992342674$1353883881@news.gmane.org> <87624si9ur.fsf@fleche.redhat.com> <001501cdccaf$ad85e9b0$0891bd10$@muller@ics-cnrs.unistra.fr> <20121207071035.GG31477@adacore.com> <50C20A66.70002@gmail.com> <29545.4593528577$1354894901@news.gmane.org> <50C21696.7040006@gmail.com> <50c21914.a750420a.2ec3.ffffe4ffSMTPIN_ADDED_BROKEN@mx.google.com> <50C222D5.4000802@redhat.com> <50C22C20.8090906@redhat.com> In-Reply-To: <50C22C20.8090906@redhat.com> Subject: RE: [RFC-v5] Fix .text section offset for windows DLL (was Calling __stdcall functions in the inferior) Date: Thu, 13 Dec 2012 10:57:00 -0000 Message-ID: <008101cdd920$907e7580$b17b6080$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-12/txt/msg00435.txt.bz2 > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=C3=A9 : vendredi 7 d=C3=A9cembre 2012 18:49 > Cc : Pierre Muller; 'asmwarrior'; 'Joel Brobecker'; 'Eli Zaretskii'; gdb- > patches@sourceware.org > Objet : Re: [RFC-v5] Fix .text section offset for windows DLL (was Calling > __stdcall functions in the inferior) >=20 > On 12/07/2012 05:09 PM, Pedro Alves wrote: > > I haven't tried to grok the patch, but Kai tells me that a section name= in > PE headers > > are stored in 8 character arrays, and are not necessarily zero-terminat= ed. > > He was wondering, and now I am too, if it wouldn't be possible to make = use > > of bfd routines to get at the necessary info, like the .text section > offset. > > E.g., bfd handles the long section name PE extension to coff (see > coffcode.h in > > bfd), though I'm not sure that needs to apply here. >=20 > Hmm, looking at: >=20 > > @@ -387,15 +391,21 @@ windows_xfer_shared_library (const char* > > struct gdbarch *gdbarch, struct obstack *obstack) > > { > > char *p; > > + struct bfd * dll; > > + CORE_ADDR text_offset; > > + > > obstack_grow_str (obstack, " > p =3D xml_escape_text (so_name); > > obstack_grow_str (obstack, p); > > xfree (p); > > obstack_grow_str (obstack, "\"> > - /* The symbols in a dll are offset by 0x1000, which is the > > - offset from 0 of the first byte in an image - because of the file > > - header and the section alignment. */ > > - obstack_grow_str (obstack, paddress (gdbarch, load_addr + 0x1000)); > > + dll =3D gdb_bfd_open_maybe_remote (so_name); > > + /* The following calls are OK even if dll is NULL. > > + The default value 0x1000 is returned by pe_text_section_offset > > + in that case. */ > > + text_offset =3D pe_text_section_offset (dll); > > + gdb_bfd_unref (dll); >=20 > I notice that this only handles native debugging. GDBserver also does > the 0x1000 add, see win32-low.c:handle_load_dll. So I'm now actually > thinking if the opposite direction may be better. That is, make > pe_text_section_offset completely independent of bfd (which it almost is), > and put it in a file under common/ so that gdbserver can use it too. Pedro, you are right that my just committed patch does not=20 fix the issue for windows gdbserver... So your idea to share the new function between gdb and gdbserver seemed indeed appealing, but when I looked at the new function pe_text_sect= ion_offset it doesn't seem so easy to me to remove bfd dependency... I will try to come up with a fix for gdbserver, but I am not sure it will be soon... Pierre Muller =20=20