From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Pedro Alves'" <palves@redhat.com>
Cc: "'asmwarrior'" <asmwarrior@gmail.com>,
"'Joel Brobecker'" <brobecker@adacore.com>,
"'Eli Zaretskii'" <eliz@gnu.org>,
<gdb-patches@sourceware.org>
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 [thread overview]
Message-ID: <008101cdd920$907e7580$b17b6080$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <50C22C20.8090906@redhat.com>
> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé : vendredi 7 décembre 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)
>
> 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-terminated.
> > 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.
>
> Hmm, looking at:
>
> > @@ -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, "<library name=\"");
> > p = xml_escape_text (so_name);
> > obstack_grow_str (obstack, p);
> > xfree (p);
> > obstack_grow_str (obstack, "\"><segment address=\"");
> > - /* 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 = 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 = pe_text_section_offset (dll);
> > + gdb_bfd_unref (dll);
>
> 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
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_section_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
next prev parent reply other threads:[~2012-12-13 10:57 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <83a9vs89r9.fsf@gnu.org>
[not found] ` <201210120953.q9C9rqfu020865@glazunov.sibelius.xs4all.nl>
[not found] ` <834nm07z0s.fsf@gnu.org>
[not found] ` <5077FEB9.4030304@redhat.com>
[not found] ` <83y5jb7rfe.fsf@gnu.org>
2012-10-15 13:36 ` [RFC] " Pierre Muller
2012-10-24 19:45 ` Joel Brobecker
2012-10-25 12:21 ` Pierre Muller
2012-11-05 17:11 ` Joel Brobecker
2012-11-06 14:31 ` [RFC-v2] " Pierre Muller
[not found] ` <50991f5f.8382440a.1100.ffff82abSMTPIN_ADDED@mx.google.com>
2012-11-07 19:44 ` Pedro Alves
2012-11-08 9:54 ` [RFC-v3] " Pierre Muller
2012-11-22 17:30 ` Joel Brobecker
2012-11-22 17:51 ` Pedro Alves
2012-11-25 22:50 ` [RFC-v4] " Pierre Muller
2012-11-26 17:22 ` Joel Brobecker
2012-11-26 18:36 ` Tom Tromey
2012-11-26 20:58 ` Joel Brobecker
[not found] ` <15690.5992342674$1353883881@news.gmane.org>
2012-11-26 4:04 ` asmwarrior
2012-11-26 10:14 ` Pierre Muller
[not found] ` <50b340fb.0aec440a.1c48.5818SMTPIN_ADDED_BROKEN@mx.google.com>
2012-11-26 11:39 ` Pedro Alves
2012-11-26 16:54 ` Tom Tromey
2012-11-27 14:59 ` [RFC-v5] " Pierre Muller
2012-12-07 7:10 ` Joel Brobecker
2012-12-07 15:23 ` asmwarrior
2012-12-07 15:41 ` Pierre Muller
[not found] ` <29545.4593528577$1354894901@news.gmane.org>
2012-12-07 16:15 ` asmwarrior
2012-12-07 16:27 ` Pierre Muller
[not found] ` <50c21914.a750420a.2ec3.ffffe4ffSMTPIN_ADDED_BROKEN@mx.google.com>
2012-12-07 17:10 ` Pedro Alves
2012-12-07 17:49 ` Pedro Alves
2012-12-13 10:57 ` Pierre Muller [this message]
2012-12-13 11:07 ` Pedro Alves
2012-12-13 11:49 ` Pedro Alves
[not found] ` <00a201cdd931$b0ee13f0$12ca3bd0$@muller@ics-cnrs.unistra.fr>
2012-12-13 14:32 ` Pedro Alves
2012-12-13 15:17 ` Pierre Muller
2012-12-13 14:33 ` Pedro Alves
2012-12-13 14:56 ` Pierre Muller
2012-12-13 15:03 ` Pedro Alves
2012-12-13 16:43 ` Pedro Alves
2012-12-13 16:54 ` Pierre Muller
2012-12-13 16:56 ` Pedro Alves
2012-12-13 17:09 ` Pierre Muller
2012-12-13 15:08 ` Pierre Muller
2012-12-13 16:04 ` Pedro Alves
[not found] ` <50c218e5.2850b40a.0281.ffffbef4SMTPIN_ADDED_BROKEN@mx.google.com>
2012-12-08 14:17 ` asmwarrior
2012-12-08 15:07 ` asmwarrior
2012-12-08 18:01 ` Pierre Muller
[not found] ` <50c38058.03d0d80a.31dd.4e28SMTPIN_ADDED_BROKEN@mx.google.com>
2012-12-09 2:45 ` asmwarrior
2012-12-09 12:45 ` Pierre Muller
[not found] ` <50c487f8.a813b40a.57d7.ffffdc7fSMTPIN_ADDED_BROKEN@mx.google.com>
2012-12-09 13:19 ` asmwarrior
2012-12-13 10:48 ` Pierre Muller
[not found] ` <37373.4003318988$1355395714@news.gmane.org>
2012-12-13 16:16 ` Tom Tromey
2012-12-13 16:21 ` Pierre Muller
[not found] ` <12936.6976012991$1355415704@news.gmane.org>
2012-12-13 20:05 ` Tom Tromey
[not found] ` <42721.1671988063$1354028360@news.gmane.org>
2012-11-28 2:44 ` asmwarrior
2012-11-29 3:40 ` asmwarrior
2012-12-12 0:59 ` asmwarrior
[not found] ` <50b2a0d1.c849420a.3a3a.3538SMTPIN_ADDED_BROKEN@mx.google.com>
2012-12-07 16:38 ` [RFC-v4] " Pedro Alves
2012-12-07 17:03 ` Pierre Muller
2012-12-07 17:50 ` Pedro Alves
[not found] ` <000301cdbd96$f5cd9f10$e168dd30$%muller@ics-cnrs.unistra.fr>
2012-11-17 10:01 ` [RFC-v3] " Eli Zaretskii
[not found] ` <006001cdaada$00c81f00$02585d00$%muller@ics-cnrs.unistra.fr>
2012-10-15 17:23 ` [RFC] " Eli Zaretskii
2012-11-03 10:36 ` Eli Zaretskii
2012-11-06 13:55 ` Pierre Muller
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='008101cdd920$907e7580$b17b6080$@muller@ics-cnrs.unistra.fr' \
--to=pierre.muller@ics-cnrs.unistra.fr \
--cc=asmwarrior@gmail.com \
--cc=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@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