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 02/15] Fix calling ifunc functions when resolver has debug info and different name
Date: Tue, 10 Apr 2018 21:20:00 -0000	[thread overview]
Message-ID: <23402c69-6c9d-ddc5-4178-2eb281900157@redhat.com> (raw)
In-Reply-To: <bd705de9-79c9-7d62-1bc5-f06a6eaaf739@simark.ca>

Hi Simon,

On 04/01/2018 04:44 AM, Simon Marchi wrote:
>> diff --git a/gdb/c-exp.y b/gdb/c-exp.y
>> index 8dc3c068a5e..e2ea07cd792 100644
>> --- a/gdb/c-exp.y
>> +++ b/gdb/c-exp.y
>> @@ -1081,7 +1081,9 @@ variable:	name_not_typename
>>  				 is important for example for "p
>>  				 *__errno_location()".  */
>>  			      symbol *alias_target
>> -				= find_function_alias_target (msymbol);
>> +				= (msymbol.minsym->type != mst_text_gnu_ifunc
>> +				   ? find_function_alias_target (msymbol)
>> +				   : NULL);
>>  			      if (alias_target != NULL)
>>  				{
>>  				  write_exp_elt_opcode (pstate, OP_VAR_VALUE);
>>
> 
> Just one question, to which I really don't have a preconceived answer:
> 
> Would it make sense to add that filtering to find_function_alias_target or
> another function deeper in the call chain instead?  In other words, would
> it ever make sense for find_function_alias_target to return an non-NULL
> result for an mst_text_gnu_ifunc minimal symbol?

For ifuncs, find_function_alias_target will finds the debug symbol for
the resolver.  If that has a different name from the ifunc (it will
if you use gcc's attribute ifunc, then it'll work the same as any other
minsym, in the sense that it'll find an alias.

So from that angle, the function works as intended, and it
wasn't clear that we'll always want to treat ifuncs differently.
Note this is the only caller of find_function_alias_target currently.

Another reason for leaving the check here is that patch #4 adds
another case of "do this for ifuncs" just above this code, but for
the "sym.symbol" case.  It felt better to keep both of the
"for ifunc, do this" cases close together.

Thanks,
Pedro Alves


  reply	other threads:[~2018-04-10 21:20 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 [this message]
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 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 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 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 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
2018-04-10 21:54       ` 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=23402c69-6c9d-ddc5-4178-2eb281900157@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