Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simark@simark.ca>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2 03/15] Calling ifunc functions when target has no debug info but resolver has
Date: Tue, 10 Apr 2018 21:48:00 -0000	[thread overview]
Message-ID: <6914cfea-6c6d-44c2-ff5d-2acc6c378016@redhat.com> (raw)
In-Reply-To: <805a18bb-d85d-f115-2e27-970ac8e8523c@simark.ca>

On 04/01/2018 05:22 AM, Simon Marchi wrote:

>> +/* See symtab.h.  */
>> +
>> +struct type *
>> +find_gnu_ifunc_target_type (CORE_ADDR resolver_funaddr)
>> +{
>> +  /* See if we can figure out the function's return type from the type
>> +     that the resolver returns.  */
>> +  symbol *sym = find_pc_function (resolver_funaddr);
>> +  if (sym != NULL
>> +      && SYMBOL_CLASS (sym) == LOC_BLOCK
>> +      && BLOCK_START (SYMBOL_BLOCK_VALUE (sym)) == resolver_funaddr)
>> +    {
> 
> This looks a lot like the "find_function_type" function.  Maybe it should use it?

Good idea.  That lives in infcall.c currently, but I moved it along.

> 
>> @@ -864,7 +878,11 @@ call_function_by_hand_dummy (struct value *function,
>>        }
>>    }
>>  
>> -  funaddr = find_function_addr (function, &values_type);
>> +  struct type *ftype = check_typedef (value_type (function));
>> +  if (TYPE_CODE (ftype) == TYPE_CODE_PTR)
>> +    ftype = check_typedef (TYPE_TARGET_TYPE (ftype));
> 
> Are these last operations necessary to do here?  It seems to me like find_function_addr
> will do pretty much the same work and ignore the input value of ftype anyway.

You're right, I did this.

> 
>> +
>> +  funaddr = find_function_addr (function, &values_type, &ftype);
>>    if (values_type == NULL)
>>      values_type = default_return_type;
>>    if (values_type == NULL)
>> diff --git a/gdb/infcall.h b/gdb/infcall.h
>> index a3861fb1bf3..bea1494b50d 100644
>> --- a/gdb/infcall.h
>> +++ b/gdb/infcall.h
>> @@ -25,8 +25,15 @@
>>  struct value;
>>  struct type;
>>  
>> +/* Determine a function's address and its return type from its value.
>> +   If the function is a GNU ifunc, then return the address of the
>> +   target function, and set *FUNCTION_TYPE to the target function's
>> +   type, and *RETVAL_TYPE to the target function's return type..
>> +   Calls error() if the function is not valid for calling.  */
>> +
>>  extern CORE_ADDR find_function_addr (struct value *function, 
>> -				     struct type **retval_type);
>> +				     struct type **retval_type,
>> +				     struct type **function_type = NULL);
> 
> Isn't the function's return value type always the target type of the function's
> type?  If so, it seems a bit redundant to have both retval_type and function_type.
> The callers easily call TYPE_TARGET_TYPE on *function_type.  Or maybe do you see
> some situations where we're able to determine the reval_type but not the
> function_type, in which case the retval_type would still be relevant?

Yeah, find_function_addr handles a case where the function's type is not
really a function, but an integer:

  else if (TYPE_CODE (ftype) == TYPE_CODE_INT)
    {

This is reached when you call a function by address, like

  (gdb) print 0x1()

In this case, the caller wouldn't be able to use
TYPE_TARGET_TYPE on function_type.  Instead it gets a 
NULL retval_type.

I think it may be possible to handle that case by making
it return the type we use for non-debug functions in function_type:

  objfile_type->nodebug_text_symbol
    = init_type (objfile, TYPE_CODE_FUNC, TARGET_CHAR_BIT,
		 "<text variable, no debug info>");

but that type is currently tied to an objfile, seemingly for no
good reason.  But I'm not sure.  It'd needs experimentation
and reworking nodebug_text_symbol, which I'd prefer to leave
for another day.

Here's what I'm squashing into the patch locally.

From 2e89a1ef27e7eac203092346da942d16bc5a606c Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Tue, 10 Apr 2018 22:46:49 +0100
Subject: [PATCH] find_function_type

---
 gdb/blockframe.c | 47 ++++++++++++++++++++++++++---------------------
 gdb/infcall.c    | 24 ++++--------------------
 gdb/infcall.h    |  2 +-
 gdb/symtab.h     |  5 +++++
 4 files changed, 36 insertions(+), 42 deletions(-)

diff --git a/gdb/blockframe.c b/gdb/blockframe.c
index db02b35742d..e6938a341ae 100644
--- a/gdb/blockframe.c
+++ b/gdb/blockframe.c
@@ -325,32 +325,37 @@ find_pc_partial_function (CORE_ADDR pc, const char **name, CORE_ADDR *address,
 
 /* See symtab.h.  */
 
+struct type *
+find_function_type (CORE_ADDR pc)
+{
+  struct symbol *sym = find_pc_function (pc);
+
+  if (sym != NULL && BLOCK_START (SYMBOL_BLOCK_VALUE (sym)) == pc)
+    return SYMBOL_TYPE (sym);
+
+  return NULL;
+}
+
+/* See symtab.h.  */
+
 struct type *
 find_gnu_ifunc_target_type (CORE_ADDR resolver_funaddr)
 {
-  /* See if we can figure out the function's return type from the type
-     that the resolver returns.  */
-  symbol *sym = find_pc_function (resolver_funaddr);
-  if (sym != NULL
-      && SYMBOL_CLASS (sym) == LOC_BLOCK
-      && BLOCK_START (SYMBOL_BLOCK_VALUE (sym)) == resolver_funaddr)
+  struct type *resolver_type = find_function_type (resolver_funaddr);
+  if (resolver_type != NULL)
     {
-      struct type *resolver_type = SYMBOL_TYPE (sym);
-      if (TYPE_CODE (resolver_type) == TYPE_CODE_FUNC)
+      /* Get the return type of the resolver.  */
+      struct type *resolver_ret_type
+	= check_typedef (TYPE_TARGET_TYPE (resolver_type));
+
+      /* If we found a pointer to function, then the resolved type
+	 is the type of the pointed-to function.  */
+      if (TYPE_CODE (resolver_ret_type) == TYPE_CODE_PTR)
 	{
-	  /* Get the return type of the resolver.  */
-	  struct type *resolver_ret_type
-	    = check_typedef (TYPE_TARGET_TYPE (resolver_type));
-
-	  /* If we found a pointer to function, then the resolved type
-	     is the type of the pointed-to function.  */
-	  if (TYPE_CODE (resolver_ret_type) == TYPE_CODE_PTR)
-	    {
-	      struct type *resolved_type
-		= TYPE_TARGET_TYPE (resolver_ret_type);
-	      if (TYPE_CODE (check_typedef (resolved_type)) == TYPE_CODE_FUNC)
-		return resolved_type;
-	    }
+	  struct type *resolved_type
+	    = TYPE_TARGET_TYPE (resolver_ret_type);
+	  if (TYPE_CODE (check_typedef (resolved_type)) == TYPE_CODE_FUNC)
+	    return resolved_type;
 	}
     }
 
diff --git a/gdb/infcall.c b/gdb/infcall.c
index d89d8ca7e8c..b233e369f27 100644
--- a/gdb/infcall.c
+++ b/gdb/infcall.c
@@ -229,20 +229,6 @@ value_arg_coerce (struct gdbarch *gdbarch, struct value *arg,
   return value_cast (type, arg);
 }
 
-/* Return the type of a function with its first instruction exactly at
-   the PC address.  Return NULL otherwise.  */
-
-static struct type *
-find_function_type (CORE_ADDR pc)
-{
-  struct symbol *sym = find_pc_function (pc);
-
-  if (sym != NULL && BLOCK_START (SYMBOL_BLOCK_VALUE (sym)) == pc)
-    return SYMBOL_TYPE (sym);
-
-  return NULL;
-}
-
 /* See infcall.h.  */
 
 CORE_ADDR
@@ -737,13 +723,12 @@ call_function_by_hand_dummy (struct value *function,
 			     void *dummy_dtor_data)
 {
   CORE_ADDR sp;
-  struct type *values_type, *target_values_type;
+  struct type *target_values_type;
   unsigned char struct_return = 0, hidden_first_param_p = 0;
   CORE_ADDR struct_addr = 0;
   struct infcall_control_state *inf_status;
   struct cleanup *inf_status_cleanup;
   struct infcall_suspend_state *caller_state;
-  CORE_ADDR funaddr;
   CORE_ADDR real_pc;
   CORE_ADDR bp_addr;
   struct frame_id dummy_id;
@@ -878,11 +863,10 @@ call_function_by_hand_dummy (struct value *function,
       }
   }
 
-  struct type *ftype = check_typedef (value_type (function));
-  if (TYPE_CODE (ftype) == TYPE_CODE_PTR)
-    ftype = check_typedef (TYPE_TARGET_TYPE (ftype));
+  type *ftype;
+  type *values_type;
+  CORE_ADDR funaddr = find_function_addr (function, &values_type, &ftype);
 
-  funaddr = find_function_addr (function, &values_type, &ftype);
   if (values_type == NULL)
     values_type = default_return_type;
   if (values_type == NULL)
diff --git a/gdb/infcall.h b/gdb/infcall.h
index bea1494b50d..8b2195019c9 100644
--- a/gdb/infcall.h
+++ b/gdb/infcall.h
@@ -28,7 +28,7 @@ struct type;
 /* Determine a function's address and its return type from its value.
    If the function is a GNU ifunc, then return the address of the
    target function, and set *FUNCTION_TYPE to the target function's
-   type, and *RETVAL_TYPE to the target function's return type..
+   type, and *RETVAL_TYPE to the target function's return type.
    Calls error() if the function is not valid for calling.  */
 
 extern CORE_ADDR find_function_addr (struct value *function, 
diff --git a/gdb/symtab.h b/gdb/symtab.h
index 22b52019ee3..83ff6f226d8 100644
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -1675,6 +1675,11 @@ extern int find_pc_partial_function_gnu_ifunc (CORE_ADDR pc, const char **name,
 extern int find_pc_partial_function (CORE_ADDR, const char **, CORE_ADDR *,
 				     CORE_ADDR *);
 
+/* Return the type of a function with its first instruction exactly at
+   the PC address.  Return NULL otherwise.  */
+
+extern struct type *find_function_type (CORE_ADDR pc);
+
 /* See if we can figure out the function's actual type from the type
    that the resolver returns.  RESOLVER_FUNADDR is the address of the
    ifunc resolver.  */
-- 
2.14.3


  reply	other threads:[~2018-04-10 21:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-25 19:19 [PATCH v2 00/15] Fixing GNU ifunc support Pedro Alves
2018-03-25 19:19 ` [PATCH v2 02/15] Fix calling ifunc functions when resolver has debug info and different name Pedro Alves
2018-04-01  3:44   ` Simon Marchi
2018-04-10 21:20     ` Pedro Alves
2018-03-25 19:19 ` [PATCH v2 08/15] Eliminate find_pc_partial_function_gnu_ifunc Pedro Alves
2018-03-25 19:19 ` [PATCH v2 01/15] Fix breakpoints in ifunc after inferior resolved it (@got.plt symbol creation) Pedro Alves
2018-04-01  3:35   ` Simon Marchi
2018-04-10 21:20     ` Pedro Alves
2018-04-14 16:36       ` Simon Marchi
2018-03-25 19:19 ` [PATCH v2 11/15] Fix stepping past GNU ifunc resolvers (introduce lookup_msym_prefer) Pedro Alves
2018-06-18 20:26   ` [PATCH] Silence GCC "uninitialized" warning on minsyms.c:lookup_minimal_symbol_by_pc_section Sergio Durigan Junior
2018-06-19 15:22     ` Pedro Alves
2018-06-19 16:55       ` Sergio Durigan Junior
2018-06-19 18:47       ` Tom Tromey
2018-03-25 19:19 ` [PATCH v2 03/15] Calling ifunc functions when target has no debug info but resolver has Pedro Alves
2018-04-01  4:22   ` Simon Marchi
2018-04-10 21:48     ` Pedro Alves [this message]
2018-04-10 21:54       ` Pedro Alves
2018-03-25 19:19 ` [PATCH v2 05/15] Fix elf_gnu_ifunc_resolve_by_got buglet Pedro Alves
2018-04-01  4:32   ` Simon Marchi
2018-04-10 21:52     ` Pedro Alves
2018-03-25 19:19 ` [PATCH v2 12/15] For PPC64/ELFv1: Introduce mst_data_gnu_ifunc Pedro Alves
2018-03-25 19:19 ` [PATCH v2 15/15] Fix resolving GNU ifunc bp locations when inferior runs resolver Pedro Alves
2018-03-25 19:19 ` [PATCH v2 07/15] Breakpoints, don't skip prologue of ifunc resolvers with debug info Pedro Alves
2018-03-25 19:25 ` [PATCH v2 04/15] Calling ifunc functions when resolver has debug info, user symbol same name Pedro Alves
2018-03-25 19:25 ` [PATCH v2 09/15] Factor out minsym_found/find_function_start_sal overload Pedro Alves
2018-03-25 19:28 ` [PATCH v2 14/15] Extend GNU ifunc testcases Pedro Alves
2018-03-25 19:29 ` [PATCH v2 10/15] For PPC64: elf_gnu_ifunc_record_cache: handle plt symbols in .text section Pedro Alves
2018-03-25 19:29 ` [PATCH v2 13/15] PPC64: always make synthetic .text symbols for GNU ifunc symbols Pedro Alves
2018-03-25 19:33   ` Pedro Alves
2018-03-26  7:54   ` Alan Modra
2018-03-25 19:29 ` [PATCH v2 06/15] Fix setting breakpoints on ifunc functions after they're already resolved Pedro Alves
2018-04-26 12:23 ` [PATCH v2 00/15] Fixing GNU ifunc support 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=6914cfea-6c6d-44c2-ff5d-2acc6c378016@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /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