Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH] hurd: Add enough auxv support for AT_ENTRY for PIE binaries
Date: Thu, 28 Dec 2017 02:19:00 -0000	[thread overview]
Message-ID: <30c5c1ec-2502-56a9-bf61-7848925e8f72@simark.ca> (raw)
In-Reply-To: <20171227154156.130174-1-samuel.thibault@ens-lyon.org>

On 2017-12-27 10:41 AM, Samuel Thibault wrote:
> gdb/ChangeLog:
> 
> 	* gdb/gnu-nat.c: Include <elf.h> and <link.h>.
> 	(gnu_xfer_auxv): New function.
> 	(gnu_xfer_partial): Call gnu_xfer_auxv when `object' is
> 	TARGET_OBJECT_AUXV.
> ---
>  gdb/ChangeLog |  7 +++++++
>  gdb/gnu-nat.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 65 insertions(+)
> 
> diff --git a/gdb/ChangeLog b/gdb/ChangeLog
> index 4d85029b99..40d8e6e1cf 100644
> --- a/gdb/ChangeLog
> +++ b/gdb/ChangeLog
> @@ -1,3 +1,10 @@
> +2017-12-22  Samuel Thibault  <samuel.thibault@ens-lyon.org>
> +
> +	* gdb/gnu-nat.c: Include <elf.h> and <link.h>.
> +	(gnu_xfer_auxv): New function.
> +	(gnu_xfer_partial): Call gnu_xfer_auxv when `object' is
> +	TARGET_OBJECT_AUXV.
> +
>  2017-12-27  Franck Jullien  <franck.jullien@gmail.com>
>  	    Stafford Horne  <shorne@gmail.com>
>  
> diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
> index 0d500ea38d..7d9c7d8dfa 100644
> --- a/gdb/gnu-nat.c
> +++ b/gdb/gnu-nat.c
> @@ -52,6 +52,8 @@ extern "C"
>  #include <setjmp.h>
>  #include <signal.h>
>  #include <sys/ptrace.h>
> +#include <elf.h>
> +#include <link.h>
>  
>  #include "inferior.h"
>  #include "symtab.h"
> @@ -2541,6 +2543,60 @@ gnu_xfer_memory (gdb_byte *readbuf, const gdb_byte *writebuf,
>      }
>  }
>  
> +/* GNU does not have auxv, but we can at least fake the AT_ENTRY entry for PIE
> +   binaries.  */
> +static enum target_xfer_status
> +gnu_xfer_auxv (gdb_byte *readbuf, const gdb_byte *writebuf,
> +	       CORE_ADDR memaddr, ULONGEST len, ULONGEST *xfered_len)
> +{
> +  task_t task = (gnu_current_inf
> +		 ? (gnu_current_inf->task
> +		    ? gnu_current_inf->task->port : 0)
> +		 : 0);
> +  process_t proc;
> +  int res;
> +  kern_return_t err;
> +  vm_address_t entry;
> +  ElfW(auxv_t) auxv[2];
> +
> +  if (task == MACH_PORT_NULL)
> +    return TARGET_XFER_E_IO;
> +  if (writebuf != NULL)
> +    return TARGET_XFER_E_IO;
> +
> +  if (memaddr == sizeof (auxv))
> +    return TARGET_XFER_EOF;
> +  if (memaddr > sizeof (auxv))
> +    return TARGET_XFER_E_IO;
> +
> +  err = proc_task2proc (proc_server, task, &proc);
> +  if (err != 0)
> +    return TARGET_XFER_E_IO;
> +
> +  /* Get entry from proc server.  */
> +  err = proc_get_entry (proc, &entry);
> +  if (err != 0)
> +    return TARGET_XFER_E_IO;
> +
> +  /* Fake auxv entry.  */
> +  auxv[0].a_type = AT_ENTRY;
> +  auxv[0].a_un.a_val = entry;
> +  auxv[1].a_type = AT_NULL;
> +  auxv[1].a_un.a_val = 0;
> +
> +  inf_debug (gnu_current_inf, "reading auxv %s[%s] --> %s",
> +	     paddress (target_gdbarch (), memaddr), pulongest (len),
> +	     host_address_to_string (readbuf));
> +
> +  if (memaddr + len > sizeof (auxv))
> +    len = sizeof (auxv) - memaddr;
> +
> +  memcpy (readbuf, (gdb_byte *) &auxv + memaddr, len);
> +  *xfered_len = len;
> +
> +  return TARGET_XFER_OK;
> +}
> +
>  /* Target to_xfer_partial implementation.  */
>  
>  static enum target_xfer_status
> @@ -2553,6 +2609,8 @@ gnu_xfer_partial (struct target_ops *ops, enum target_object object,
>      {
>      case TARGET_OBJECT_MEMORY:
>        return gnu_xfer_memory (readbuf, writebuf, offset, len, xfered_len);
> +    case TARGET_OBJECT_AUXV:
> +      return gnu_xfer_auxv (readbuf, writebuf, offset, len, xfered_len);
>      default:
>        return TARGET_XFER_E_IO;
>      }
> 

Hi Samuel,

As I said in the previous thread, the patch looks good to me, but
I don't have a setup to test.  I would like to leave some time for
others to comment, especially because I don't expect people to be
very active these days.  If nobody has commented by the time we are
ready to create the 8.1 branch (supposed to be in January), we'll
merge it.  I'll add a note to the GDB 8.1 release wiki page [1] so
we don't forget.  Does that sound good to you?

In the mean time, I'd like to add some details to the commit message
about how this is expected to work.  The AT_ENTRY value set here
will be read by the svr4_exec_displacement function, is that right?

Thanks,

Simon

[1] https://sourceware.org/gdb/wiki/GDB_8.1_Release


  reply	other threads:[~2017-12-28  2:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-27 15:42 Samuel Thibault
2017-12-28  2:19 ` Simon Marchi [this message]
2017-12-28 21:27   ` Samuel Thibault
2018-01-08 15:41     ` Simon Marchi

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=30c5c1ec-2502-56a9-bf61-7848925e8f72@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=samuel.thibault@ens-lyon.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