From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>,
Binutils Development <binutils@sourceware.org>,
GDB Patches <gdb-patches@sourceware.org>,
"H.J. Lu" <hjl.tools@gmail.com>
Subject: Re: [PATCH/RFC 01/02 v2] Refactor PRPSINFO handling on Binutils
Date: Thu, 10 Jan 2013 18:26:00 -0000 [thread overview]
Message-ID: <50EF07C8.3050307@redhat.com> (raw)
In-Reply-To: <m3a9sp7e93.fsf@redhat.com>
On 01/04/2013 04:39 AM, Sergio Durigan Junior wrote:> +++ b/bfd/elf-psinfo.h
> @@ -0,0 +1,124 @@
> +/* Definitions for PRPSINFO structures under ELF on GNU/Linux.
What about other OSs, like e.g., Solaris?
> +/* External 64-bit structure for PRPSINFO. This structure is ABI-defined,
> + thus we choose to use char arrays here in order to avoid dealing with
> + different types in different architectures.
> +
> + Differently from the 32-bit version, the PowerPC guys made our lives better
> + and used the same size as the other architectures.
In the current revision, this comment appears out of the blue.
Better would be to instead add a comment further up, above the
32-bit version stating that these are used by most architectures,
although some define their own versions (like e.g., PPC).
> +
> + This structure will ultimately be written in the corefile's note section,
> + as the PRPSINFO. */
> +
> +struct elf_external_prpsinfo64
> +#define PRPSINFO32_COPY_FIELDS(abfd, from, to) \
> + do \
Personally, I'd prefer calling these SWAP instead
of COPY, as you're not really doing straight
copying, and "swap" is what bfd calls this idiom
about everywhere.
...
> +/* Process info. In the end we do provide typedefs for them. */
> +
> +typedef struct elf_external_prpsinfo32 prpsinfo32;
> +typedef struct elf_external_prpsinfo64 prpsinfo64;
What's the point of these typedefs? To me, they just
obscure things, and are easily confused with the host
types...
> @@ -8165,7 +8166,7 @@ elfcore_grok_arm_vfp (bfd *abfd, Elf_Internal_Note *note)
> #if defined (HAVE_PRPSINFO_T)
> typedef prpsinfo_t elfcore_psinfo_t;
> #if defined (HAVE_PRPSINFO32_T) /* Sparc64 cross Sparc32 */
> -typedef prpsinfo32_t elfcore_psinfo32_t;
> +typedef prpsinfo32 elfcore_psinfo32_t;
... like here. HAVE_PRPSINFO32_T/prpsinfo32_t were
about a host type. prpsinfo32 is always defined (it's a
bfd type). This in fact looks suspiciously wrong, and a
potential breakage if in fact Sparc32 has a different
psinfo32_t (what OS was that?), or in the other spots,
some other arcane port/OS/arch having a different psinfo32_t
than the Linux one. Either the #ifdef can be removed and
this made unconditional, and host independent (the best),
or the type should remain the host type (until all ports
convert to implement elf_backend_write_core_note&co
host-independent hooks).
> #endif
> #endif
>
> + The reason why we have a different structure only for PPC is because
> + on this architecture (and *only* here!) the size of 32-bit structure
This "only here" bit of the comment should go away, because
it'll generate confusion whenever some other arch needs
its own structure, making this outdated, because nobody
will remember to update it.
> @@ -415,14 +417,13 @@ elf_x86_64_grok_psinfo (bfd *abfd, Elf_Internal_Note *note)
> return TRUE;
> }
>
> -#ifdef CORE_HEADER
> static char *
> elf_x86_64_write_core_note (bfd *abfd, char *buf, int *bufsiz,
> int note_type, ...)
> {
...
> case NT_PRSTATUS:
> +#ifdef CORE_HEADER
> va_start (ap, note_type);
> pid = va_arg (ap, long);
> cursig = va_arg (ap, int);
> @@ -498,10 +501,13 @@ elf_x86_64_write_core_note (bfd *abfd, char *buf, int *bufsiz,
> return elfcore_write_note (abfd, buf, bufsiz, "CORE", note_type,
> &prstat, sizeof (prstat));
> }
> +#else
> + return NULL;
> +#endif /* CORE_HEADER */
> }
> /* NOTREACHED */
> }
> -#endif
> +
Do you plan on following up with similar treatment for prstatus?
Thanks for doing this,
--
Pedro Alves
next prev parent reply other threads:[~2013-01-10 18:26 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
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 [this message]
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=50EF07C8.3050307@redhat.com \
--to=palves@redhat.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=jan.kratochvil@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