From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org, thomas@schwinge.name, bug-hurd@gnu.org
Subject: Re: [PATCH,HURD] Fix reading core
Date: Wed, 10 Apr 2013 11:33:00 -0000 [thread overview]
Message-ID: <20130409234117.GC24389@adacore.com> (raw)
In-Reply-To: <20130211020109.GK5926@type.youpi.perso.aquilenet.fr>
> The i386 GNU/Hurd ELF core format actually follows the uaccess gregset_t
> array format, not the Mach thread state format. This fixes gdb reading
> it.
>
> * gdb/i386gnu-nat.c (CREG_OFFSET): New macro.
> (creg_offset): New array.
> (CREG_ADDR): Use creg_offset instead of reg_offset.
Did anyone review this? I don't know GNU/Hurd, but the patch looks
very plausible.
Do you have write access to the GDB repository? If not, do you have
copyright assignment papers on file? This patch is small enough that
we can take it as a tiny patch, but if you think you're going to
send more patches, we should probably get you started on those.
The ChangeLog entry above needs to be indented properly (just to be
sure). Another tiny style nitpick below...
> --- a/gdb/i386gnu-nat.c.original 2013-02-11 00:46:02.000000000 +0000
> +++ b/gdb/i386gnu-nat.c 2013-02-11 00:48:09.000000000 +0000
> @@ -56,8 +56,21 @@
> REG_OFFSET (ds), REG_OFFSET (es), REG_OFFSET (fs), REG_OFFSET (gs)
> };
>
> +/* Offset to the greg_t location where REG is stored. */
> +#define CREG_OFFSET(reg) (REG_##reg * 4)
> +
> +/* At CREG_OFFSET[N] is the offset to the greg_t location where
> + the GDB register N is stored. */
> +static int creg_offset[] =
> +{
> + CREG_OFFSET (EAX), CREG_OFFSET (ECX), CREG_OFFSET (EDX), CREG_OFFSET (EBX),
> + CREG_OFFSET (UESP), CREG_OFFSET (EBP), CREG_OFFSET (ESI), CREG_OFFSET (EDI),
> + CREG_OFFSET (EIP), CREG_OFFSET (EFL), CREG_OFFSET (CS), CREG_OFFSET (SS),
> + CREG_OFFSET (DS), CREG_OFFSET (ES), CREG_OFFSET (FS), CREG_OFFSET (GS)
> +};
Unless it was done on purpose, we try to limit the size of lines
to 70 characters, only extending it to up to 80 when it makes
a difference....
> +
> #define REG_ADDR(state, regnum) ((char *)(state) + reg_offset[regnum])
> -#define CREG_ADDR(state, regnum) ((const char *)(state) + reg_offset[regnum])
> +#define CREG_ADDR(state, regnum) ((const char *)(state) + creg_offset[regnum])
>
> \f
> /* Get the whole floating-point state of THREAD and record the values
--
Joel
next prev parent reply other threads:[~2013-04-09 23:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-11 2:01 Samuel Thibault
2013-04-10 11:33 ` Joel Brobecker [this message]
2013-04-11 2:44 ` Thomas Schwinge
2013-04-11 3:55 ` Samuel Thibault
2013-04-11 14:08 ` Thomas Schwinge
2013-04-26 17:50 ` Samuel Thibault
2013-04-26 19:02 ` Joel Brobecker
2013-04-26 19:03 ` Alfred M. Szmidt
2013-04-30 12:02 ` Thomas Schwinge
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=20130409234117.GC24389@adacore.com \
--to=brobecker@adacore.com \
--cc=bug-hurd@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=thomas@schwinge.name \
/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