From: "H.J. Lu" <hjl.tools@gmail.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Binutils Development <binutils@sourceware.org>,
GDB Patches <gdb-patches@sourceware.org>,
Pedro Alves <palves@redhat.com>
Subject: Re: [PATCH/RFC 01/02 v2] Refactor PRPSINFO handling on Binutils
Date: Mon, 17 Dec 2012 15:43:00 -0000 [thread overview]
Message-ID: <CAMe9rOrPzqxx=sZh_jDywEiN5LHcRzx6ZOrtGdPt2UFswr4LxA@mail.gmail.com> (raw)
In-Reply-To: <m3k3shv0g5.fsf@redhat.com>
On Sun, Dec 16, 2012 at 7:09 PM, Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
> Hi,
>
> This is a follow-up on:
> <http://sourceware.org/ml/binutils/2012-11/msg00240.html>
>
> Sorry for the delay on this. I addressed Pedro's and H.J.'s comments,
> and took some time to test the patch on different architectures.
>
> It also took me some time to decide the best way to handle several
> little issues that I was facing: different declarations for PPC needed,
> different declarations for PRPSINFO structures, etc.
>
> Anyway, I hope I managed to solve these problems, but I would really
> appreciate some comments (if you have, of course) about the code. The
> idea was to simplify the handling of PRPSINFO, so:
>
> 1) I created elf_{internal,external}_prpsinfo* structures, organized
> differently according to their purposes.
>
> 2) I created the new PRPSINFO*_COPY_FIELDS macros, which take care of
> (duh) copying the fields from the internal to the external structures,
> obeying bitness and such.
>
> 3) I also took the liberty to implement the i386 version of the
> *_write_core_note.
>
> 4) I removed some dependency on the CORE_HEADER macro (suggested by
> Pedro). Not sure if everything is correct, though.
>
> Anyway, I guess those are the main changes. Please let me know if you
> have some question about the patch. Thanks.
>
> +
> +static char *
> +elf_i386_write_core_note (bfd *abfd, char *buf, int *bufsiz,
> + int note_type, ...)
> +{
> + const struct elf_backend_data *bed = get_elf_backend_data (abfd);
> + va_list ap;
> + const struct elf_internal_prpsinfo *prpsinfo;
> + long pid;
> + int cursig;
> + const void *gregs;
> + struct elf_external_prpsinfo32 data;
> +
> + switch (note_type)
> + {
> + default:
> + return NULL;
> +
> + case NT_PRPSINFO:
> + va_start (ap, note_type);
> + prpsinfo = va_arg (ap, const struct elf_internal_prpsinfo *);
> + va_end (ap);
> +
> + memset (&data, 0, sizeof (data));
> + PRPSINFO32_COPY_FIELDS (abfd, prpsinfo, data);
> +
> + return elfcore_write_note (abfd, buf, bufsiz, "CORE", note_type,
> + &data, sizeof (data));
> + /* NOTREACHED */
> +
> + case NT_PRSTATUS:
> + va_start (ap, note_type);
> + pid = va_arg (ap, long);
> + cursig = va_arg (ap, int);
> + gregs = va_arg (ap, const void *);
> + va_end (ap);
> +
> + if (bed->elf_machine_code == EM_X86_64)
> + {
> + prstatusx32_t prstat;
> + memset (&prstat, 0, sizeof (prstat));
> + prstat.pr_pid = pid;
> + prstat.pr_cursig = cursig;
> + memcpy (&prstat.pr_reg, gregs, sizeof (prstat.pr_reg));
> + return elfcore_write_note (abfd, buf, bufsiz, "CORE", note_type,
> + &prstat, sizeof (prstat));
> + }
> + else
When will elf_i386_write_core_note be called for
x32 process?
--
H.J.
next prev parent reply other threads:[~2012-12-17 15:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-17 3:10 Sergio Durigan Junior
2012-12-17 15:43 ` H.J. Lu [this message]
2012-12-17 17:41 ` Sergio Durigan Junior
2012-12-17 17:44 ` H.J. Lu
2012-12-17 17:51 ` Sergio Durigan Junior
2012-12-17 22:01 ` H.J. Lu
2012-12-18 5:47 ` Sergio Durigan Junior
2012-12-18 15:43 ` H.J. Lu
2012-12-18 17:38 ` Jan Kratochvil
2012-12-18 19:19 ` Sergio Durigan Junior
2012-12-18 19:43 ` Jan Kratochvil
2012-12-30 1:49 ` Sergio Durigan Junior
2013-01-01 14:30 ` Jan Kratochvil
2013-01-02 23:32 ` Sergio Durigan Junior
2013-01-03 13:44 ` Jan Kratochvil
2013-01-03 15:46 ` Sergio Durigan Junior
2013-01-04 4:40 ` Sergio Durigan Junior
2013-01-09 20:49 ` Sergio Durigan Junior
2013-01-10 18:26 ` Pedro Alves
2013-01-10 19:47 ` Sergio Durigan Junior
2013-01-11 15:45 ` Pedro Alves
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='CAMe9rOrPzqxx=sZh_jDywEiN5LHcRzx6ZOrtGdPt2UFswr4LxA@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=sergiodj@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