Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: Joel Brobecker <brobecker@adacore.com>,
	       gdb-patches ml <gdb-patches@sourceware.org>
Subject: Re: [RFA] Define Elf32_auxv_t and Elf64_auxv_t if not available.
Date: Thu, 29 Mar 2012 16:03:00 -0000	[thread overview]
Message-ID: <4F74879B.6070908@redhat.com> (raw)
In-Reply-To: <1332893506.16415.4.camel@hactar>

Hello Thiago,

On 03/28/2012 01:11 AM, Thiago Jung Bauermann wrote:

> On Tue, 2012-03-27 at 08:20 -0700, Joel Brobecker wrote:
>>> > > 2012-03-26  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>


>>> > > diff --git a/gdb/gdbserver/configure.ac b/gdb/gdbserver/configure.ac
>>> > > index e6e9162..6b98dc0 100644
>>> > > --- a/gdb/gdbserver/configure.ac
>>> > > +++ b/gdb/gdbserver/configure.ac
>>> > > @@ -163,9 +163,10 @@ fi
>>> > >  
>>> > >  AC_CHECK_DECLS([strerror, perror, memmem, vasprintf, vsnprintf])
>>> > >  
>>> > > -AC_CHECK_TYPES(socklen_t, [], [],
>>> > > +AC_CHECK_TYPES([socklen_t, Elf32_auxv_t, Elf64_auxv_t], [], [],
>>> > >  [#include <sys/types.h>
>>> > >  #include <sys/socket.h>
>>> > > +#include <elf.h>
>>> > >  ])
>> > 
>> > I wonder if we shouldn't be using two separate checks here. Seems
>> > unlikely to be a problem in practice, but we're looking for for
>> > a type is <sys/types.h> + <sys/socket.h>, and then looking for another
>> > collection of types in <elf.h>. We know we're most likely not going
>> > to get any "cross-polination" finding socklen_t in <elf.h>, but if
>> > this sort of thing were to happen, we would be in a situation where
>> > the configure check finds the type, but the code (which presumably
>> > might only include types.h and sockets.h) does not, leading to a build
>> > error.
> That's a good point, I didn't think of that. Like you say it's unlikely
> to happen in practice but it's cleaner indeed.


Separate tests is definitely the way to go, but for the reason that you'd
be always breaking the socklen_t test on non-elf ports, such
as the Windows port, where elf.h doesn't even exist.

> 2012-03-27  Thiago Jung Bauermann  <thiago.bauermann@linaro.org>
>
>         * configure.ac: Check whether Elf32_auxv_t and Elf64_auxv_t
> 	are available.
> 	linux-low.c [HAVE_ELF32_AUXV_T] (Elf32_auxv_t): Add typedef.
> 	[HAVE_ELF64_AUXV_T] (Elf64_auxv_t): Likewise.
> 	* config.in: Regenerate.
> 	* configure: Likewise.

This version looks good to me.


A "Copied from glibc's elf.h." small comment here would be good,
I think.  Otherwise, the "We use to have pointer elements added here"
comment is misleading.  :-)

> +#ifndef HAVE_ELF32_AUXV_T
> +typedef struct
> +{
> +  uint32_t a_type;		/* Entry type */
> +  union
> +    {
> +      uint32_t a_val;		/* Integer value */
> +      /* We use to have pointer elements added here.  We cannot do that,
> +	 though, since it does not work when using 32-bit definitions
> +	 on 64-bit platforms and vice versa.  */
> +    } a_un;
> +} Elf32_auxv_t;
> +#endif
> +

-- 
Pedro Alves


  reply	other threads:[~2012-03-29 16:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26 18:49 Thiago Jung Bauermann
2012-03-27 15:21 ` Joel Brobecker
2012-03-28  0:12   ` Thiago Jung Bauermann
2012-03-29 16:03     ` Pedro Alves [this message]
2012-03-30 20:26       ` Thiago Jung Bauermann

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=4F74879B.6070908@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=thiago.bauermann@linaro.org \
    /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