Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Alan Hayward <Alan.Hayward@arm.com>
To: Ulrich Weigand <uweigand@de.ibm.com>,
	Pedro Franco de Carvalho	<pedromfc@linux.ibm.com>
Cc: Simon Marchi <simark@simark.ca>,
	"gdb-patches\\@sourceware.org"	<gdb-patches@sourceware.org>,
	nd <nd@arm.com>, "anton@linux.ibm.com"	<anton@linux.ibm.com>
Subject: Re: [PATCH 2/2] gdbserver: Add linux_get_hwcap
Date: Mon, 08 Apr 2019 09:38:00 -0000	[thread overview]
Message-ID: <D92D5717-3F2E-4DB4-A7A4-86DA22587463@arm.com> (raw)
In-Reply-To: <20190405163946.2DB32D802DA@oc3748833570.ibm.com>

Apologies, I’ve been away for the last week, only just saw this whole thread.
Thanks for fixing this without me.

Pedro: Some comments/nits below.  Given this is pushed, I’m happy if you don’t
raise a whole new patch for it.


> On 5 Apr 2019, at 17:39, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> 
> Pedro Franco de Carvalho wrote: 
> 
>> Note that there is a difference in the interface between linux_get_auxv
>> and linux_get_hwcap(2), the latter still return both the status and the
>> entry value, but I didn't want to change all their users.
> 
> Actually, I think this is fine -- for hwcap, 0 is a natural default
> value to use if the entry is not present.

Yes, all the targets in GDB treated an error condition the same as a hwcap
value of 0.  Which is sensible given it’s for checking features present in
the hardware/cpu.

> 
>> Also, contrary to the gdb client version (target_auxv_search
>> gdb/auxv.c), this one doesn't differentiate between an error and the
>> entry not being found.
> 
> That also seems reasonable.  If anybody requires more specific error
> handling, that can always be added later.


Originally I was going to keep gdbserver linux_get_auxv with the same returns
as the gdb version.  However, given it is a static function and the hwap
functions were not checking the error value, I removed it.

> 
>> gdb/gdbserver/ChangeLog:
>> 2019-04-DD  Pedro Franco de Carvalho  <pedromfc@linux.ibm.com>
>> 
>> 	* linux-low.c (linux_get_auxv): Remove static.  Return auxv entry
>> 	value in argument pointer, return 1 if the entry is found and 0
>> 	otherwise.  Move comment.

Returning true/false would have been better than 1/0. The build requires C++ support.

>> 	(linux_get_hwcap, linux_get_hwcap2): Use modified linux_get_auxv.
>> 	* linux-low.h (linux_get_auxv): Declare.
>> 	* linux-ppc-low.c (is_elfv2_inferior): Use linux_get_auxv.
> 


> index d825184835..d5d074efc5 100644
> --- a/gdb/gdbserver/linux-low.h
> +++ b/gdb/gdbserver/linux-low.h
> @@ -435,6 +435,14 @@ bool thread_db_thread_handle (ptid_t ptid, gdb_byte **handle, int *handle_len);
> 
> extern int have_ptrace_getregset;
> 
> +/* Search for the value with type MATCH in the auxv vector with
> +   entries of length WORDSIZE bytes.  If found, store the value in
> +   *VALP and return 1.  If not found or if there is an error, return
> +   0.  */

Comment should state that VALP is not checked for nullptr.

> +
> +int linux_get_auxv (int wordsize, CORE_ADDR match,
> +		    CORE_ADDR *valp);
> +



> 
> diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
> index 265043f97e..65919c3262 100644
> --- a/gdb/gdbserver/linux-low.c
> +++ b/gdb/gdbserver/linux-low.c
> @@ -7427,11 +7427,10 @@ linux_get_pc_64bit (struct regcache *regcache)
>   return pc;
> }
> 
> -/* Fetch the entry MATCH from the auxv vector, where entries are length
> -   WORDSIZE.  If no entry was found, return zero.  */
> +/* See linux-low.h.  */
> 
> -static CORE_ADDR
> -linux_get_auxv (int wordsize, CORE_ADDR match)
> +int
> +linux_get_auxv (int wordsize, CORE_ADDR match, CORE_ADDR *valp)
> {
>   gdb_byte *data = (gdb_byte *) alloca (2 * wordsize);
>   int offset = 0;

Would be useful to set valp to zero here. (Not sure if the GDB version
does this either).

> @@ -7442,15 +7441,21 @@ linux_get_auxv (int wordsize, CORE_ADDR match)
>     {
>       if (wordsize == 4)
> 	{
> -	  uint32_t *data_p = (uint32_t *)data;
> +	  uint32_t *data_p = (uint32_t *) data;
> 	  if (data_p[0] == match)
> -	    return data_p[1];
> +	    {
> +	      *valp = data_p[1];
> +	      return 1;
> +	    }
> 	}
>       else
> 	{
> -	  uint64_t *data_p = (uint64_t *)data;
> +	  uint64_t *data_p = (uint64_t *) data;
> 	  if (data_p[0] == match)
> -	    return data_p[1];
> +	    {
> +	      *valp = data_p[1];
> +	      return 1;
> +	    }
> 	}



> diff --git a/gdb/gdbserver/linux-ppc-low.c b/gdb/gdbserver/linux-ppc-low.c
> index 8deb0ce068..f17f05a0a3 100644
> --- a/gdb/gdbserver/linux-ppc-low.c
> +++ b/gdb/gdbserver/linux-ppc-low.c
> @@ -1107,10 +1107,13 @@ is_elfv2_inferior (void)
> #else
>   const int def_res = 0;
> #endif
> -  unsigned long phdr;
> +  CORE_ADDR phdr;
>   Elf64_Ehdr ehdr;
> 
> -  if (!ppc_get_auxv (AT_PHDR, &phdr))
> +  const struct target_desc *tdesc = current_process ()->tdesc;
> +  int wordsize = register_size (tdesc, 0);
> +
> +  if (!linux_get_auxv (wordsize, AT_PHDR, &phdr))
>     return def_res;

I don’t think there is a requirement here for the error to be return separately
to the phdr. With the my version of linux_get_auxv, on error you would get 0
for phdr. Given that it is an address, 0 should never be a valid value.

With the code pre my patch and this patch, I’m not sure what will happen if the
PHDR value is 0 - will read_inferior_memory then the memcmp deal with that? (To
be fair, I suspect there are bigger issues to deal with if phdr is 0).

Therefore I’d suggest it’d be better to have:

CORE_ADDR phdr = linux_get_auxv (wordsize, AT_PHDR);
if (phdr == nullptr)
  return def_res;



Thanks,
Alan.




  parent reply	other threads:[~2019-04-08  9:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25 12:05 [PATCH 1/2] " Alan Hayward
2019-03-25 12:05 ` [PATCH 2/2] gdbserver: " Alan Hayward
2019-03-25 15:41   ` Simon Marchi
2019-03-26 13:17     ` Alan Hayward
     [not found]       ` <353e83d9-efb3-c485-9ae6-6fc0a1f54553@simark.ca>
     [not found]         ` <57CEBD0C-44A5-48D1-8CEB-54584E1A1A21@arm.com>
     [not found]           ` <59A457A2-F464-4A05-A471-700F066114AD@arm.com>
2019-03-26 14:34             ` FW: " Alan Hayward
2019-03-28  9:50               ` Ulrich Weigand
2019-03-28 11:35                 ` Alan Hayward
2019-03-29 23:12                   ` Ulrich Weigand
2019-04-03 19:13                     ` Pedro Franco de Carvalho
2019-04-04 13:49                       ` Ulrich Weigand
2019-04-05 16:26                         ` Pedro Franco de Carvalho
2019-04-05 16:39                           ` Ulrich Weigand
2019-04-05 17:23                             ` Pedro Franco de Carvalho
2019-04-08  9:38                             ` Alan Hayward [this message]
2019-04-11 14:12                               ` Pedro Franco de Carvalho
2019-03-26 14:56             ` FW: " Simon Marchi
2019-04-02 22:00   ` Peter Bergner
2019-04-04 21:22     ` Pedro Franco de Carvalho
2019-03-25 15:18 ` [PATCH 1/2] " Simon Marchi
2019-03-25 16:51   ` Alan Hayward

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=D92D5717-3F2E-4DB4-A7A4-86DA22587463@arm.com \
    --to=alan.hayward@arm.com \
    --cc=anton@linux.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nd@arm.com \
    --cc=pedromfc@linux.ibm.com \
    --cc=simark@simark.ca \
    --cc=uweigand@de.ibm.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