From: Joel Brobecker <brobecker@adacore.com>
To: Alan Hayward <Alan.Hayward@arm.com>
Cc: Pedro Alves <palves@redhat.com>, Yao Qi <qiyaoltc@gmail.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
nd <nd@arm.com>
Subject: Re: [PATCH PR gdb/22736] [aarch64] gdb crashes on a conditional breakpoint with cast return type
Date: Fri, 09 Mar 2018 08:51:00 -0000 [thread overview]
Message-ID: <20180309085122.v4fzh4vcii5plkkk@adacore.com> (raw)
In-Reply-To: <DDA6BBB3-C085-4818-8B87-20CFAE19E6FE@arm.com>
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?
> In call_function_by_hand_dummy() there already exists code to extract
> the type of the function return, which is set as target_values_type.
> Patch below simply passes this through to the gdbarch_push_dummy_call
> method. Updated aarch64 and arm targets to use this.
>
> If this patch is ok for amd64/aarch64/arm, then I will post again with
> _push_dummy_call() fixed on every target. (Not done that yet because
> itâs a lot of tedious copy pasting). Most targets donât even look at
> the return types, so Iâm not expecting many issues when I look at
> them.
Sounds like a good change even if we didn't have this issue, as
it avoids a gdbarch method having to re-compute something that was
already previously computed.
> 2018-03-06 Alan Hayward <alan.hayward@arm.com>
>
> PR gdb/22736
> * aarch64-tdep.c (aarch64_push_dummy_call): Use passed in return type.
> * amd64-tdep.c (amd64_push_dummy_call): Add new arg.
> * arm-tdep.c (arm_push_dummy_call): Use passed in return type.
> * gdbarch.sh (gdbarch_push_dummy_call): Add return type.
> * gdbarch.h: Regenerate.
> * gdbarch.sh: Likewise.
> * infcall.c (call_function_by_hand_dummy): Pass down return type.
Just a minor comment below (besides what you already remarked on about
updating the remaining targets). Please give Pedro some time to comment;
my reviews have not be exactly top notch, lately, and I don't want you
to do useless work because I missed something.
> @@ -1411,20 +1410,11 @@ aarch64_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
> Rather that change the target interface we call the language code
> directly ourselves. */
>
> - func_type = check_typedef (value_type (function));
> -
> - /* Dereference function pointer types. */
> - if (TYPE_CODE (func_type) == TYPE_CODE_PTR)
> - func_type = TYPE_TARGET_TYPE (func_type);
> -
> - gdb_assert (TYPE_CODE (func_type) == TYPE_CODE_FUNC
> - || TYPE_CODE (func_type) == TYPE_CODE_METHOD);
> -
> /* If language_pass_by_reference () returned true we will have been
> given an additional initial argument, a hidden pointer to the
> return slot in memory. */
> - return_type = TYPE_TARGET_TYPE (func_type);
> - lang_struct_return = language_pass_by_reference (return_type);
> + if (return_type != nullptr)
I think return_type can never be nullptr (from what I understand of
the code in call_function_by_hand_dummy).
--
Joel
next prev parent reply other threads:[~2018-03-09 8:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 17:03 Alan Hayward
2018-03-02 3:32 ` Joel Brobecker
2018-03-02 12:09 ` Alan Hayward
[not found] ` <CAH=s-PP-Xy7TrP-0zKCuA2X4A8Xgx_gHNvYewm41LPs7ZZJniA@mail.gmail.com>
2018-03-02 14:05 ` Alan Hayward
2018-03-02 15:18 ` Joel Brobecker
2018-03-05 15:57 ` Alan Hayward
2018-03-05 16:45 ` Pedro Alves
2018-03-07 11:10 ` Alan Hayward
2018-03-09 8:51 ` Joel Brobecker [this message]
2018-03-09 16:04 ` Pedro Alves
2018-03-09 16:44 ` Yao Qi
2018-03-09 19:11 ` Alan Hayward
2018-03-02 10:07 ` Yao Qi
2018-05-26 0:59 Weimin Pan
2018-05-27 3:42 ` Simon Marchi
2018-05-29 17:43 ` Wei-min Pan
2018-05-29 21:37 ` Simon Marchi
2018-05-30 0:29 ` Weimin Pan
2018-05-29 17:46 ` 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=20180309085122.v4fzh4vcii5plkkk@adacore.com \
--to=brobecker@adacore.com \
--cc=Alan.Hayward@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=nd@arm.com \
--cc=palves@redhat.com \
--cc=qiyaoltc@gmail.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