Re: [PATCH PR gdb/22736] [aarch64] gdb crashes on a conditional breakpoint with cast return type

[Alan Hayward <Alan.Hayward@arm.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3036 bytes --]



> On 9 Mar 2018, at 08:51, Joel Brobecker <brobecker@adacore.com> wrote:
> 
> Hello Alan,
> 
>> The target type for the *function is set to the type of the function
>> pointer, not the return type.  So, for IFUNC, TYPE_CODE_FUNC target type
>> is TYPE_CODE_INT which gives the type of the function pointer. For the
>> FUNC, there is no pointer, so the target type of TYPE_CODE_FUNC is set
>> to null. That makes sense to me, but isn’t immediately obvious.
> 
> I don't really understand what you mean by that -- maybe it is related
> to the '*' before 'function' above? If we're talking about the
> target_type for the function, it should be the type of the return value.
> At least according to the documentation for that field in gdb_types.h.
> But maybe you're talking about something else?

Agreed that the documentation says “type” should contain the type of the
function return.

I’m not quite sure on the terminology here, but, what the gdb code is picking
up and placing into type is the type of the function entry in the elf file.
The code in find_minsym_type_and_address() ensures that a FUNC will always
have the type nodebug_text_gnu_ifunc_symbol and an IFUNC will always have
the type nodebug_text_symbol.  This is completely unrelated to the return type
of the function, which is only resolved much later in call_function_by_hand_dummy().

In an ideal world, maybe the common code needs a bit of a rewrite:
The function structure needs to contain both the type of the elf entry and the
type of the return value. But, the existing value* and function* structures don’t
really support adding extra fields. I wasn’t really comfortable enough will this part
of the code to meddle with that.

Happy with the other comments too. Thanks!


> On 9 Mar 2018, at 16:04, Pedro Alves <palves@redhat.com> wrote:
> 
> Sorry for the constant delays the past couple weeks.  I've been getting
> distracted by other things more than usual.  Today I'm trying to finish/post
> the ifunc-fixing series I pointed at earlier, and hopefully that will give
> me enough background to understand/review this patch (I'm afraid I haven't
> really looked at it in any detail).
> 

Ok, happy to wait until you have some time. I’m looking at pr/22943 which also
might help with my understanding of this one a little more.

> 
> On 9 Mar 2018, at 16:44, Yao Qi <qiyaoltc@gmail.com> wrote:
> 
> FWIW, this issue is *not* related to ifunc.  As Alan described in
> previous email, ifunc symbol is OK, but normal function symbol's target
> type is NULL, because without debug information, GDB doesn't know the
> symbol is a function or not.  I thought about it, but I am not confident
> that we can set symbol's target type (for example, set it void or int)
> in absent of debug information.
> 

I’d just add that even with IFUNC the type will always be set to a pointer to an
Int, regardless of the return type of the function.




Alan.

\x16º&Öéj×!zÊÞ¶êç׎|ï™b²Ö«r\x18\x1dn–­r\x17¬