From: Alan Hayward <Alan.Hayward@arm.com>
To: Pedro Alves <palves@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
nd <nd@arm.com>
Subject: Re: [PATCH v2 1/2] Add lang_struct_return to _push_dummy_call
Date: Wed, 10 Oct 2018 11:54:00 -0000 [thread overview]
Message-ID: <C1091CDD-98C6-4561-B654-130BFA5194A7@arm.com> (raw)
In-Reply-To: <5ce2656e-1ba6-bbab-48a6-7a12dea92a61@redhat.com>
> On 9 Oct 2018, at 17:14, Pedro Alves <palves@redhat.com> wrote:
>
> On 10/01/2018 04:52 PM, Alan Hayward wrote:
>> Make call_function_by_hand_dummy pass this down.
>>
>> 2018-10-01 Alan Hayward <alan.hayward@arm.com>
>>
>
>> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
>> index 023e8eb453..504b040c2e 100644
>> --- a/gdb/aarch64-tdep.c
>> +++ b/gdb/aarch64-tdep.c
>> @@ -1512,8 +1512,8 @@ pass_in_v_vfp_candidate (struct gdbarch *gdbarch, struct regcache *regcache,
>> static CORE_ADDR
>> aarch64_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
>> struct regcache *regcache, CORE_ADDR bp_addr,
>> - int nargs,
>> - struct value **args, CORE_ADDR sp, int struct_return,
>> + int nargs, struct value **args, CORE_ADDR sp,
>> + int struct_return, int lang_struct_return_unused,
>
> Here this is called "lang_struct_return_unused", but all the other
> cases were just "lang_struct_return".
>
> I suppose it'd be clearer if "struct_return" were renamed to
> "abi_struct_return", but I empathize with not having
> changed it in this patch…
>
This was because lang_struct_return is already a local parameter within aarch64_push_dummy_call.
The next patch renames the function arg back to lang_struct_return.
(However, if I do the enum below it should remove that issue).
>> CORE_ADDR struct_addr)
>> {
>> int argnum;
>
>
>> --- a/gdb/gdbarch.sh
>> +++ b/gdb/gdbarch.sh
>> @@ -485,7 +485,7 @@ M;struct frame_id;dummy_id;struct frame_info *this_frame;this_frame
>> # deprecated_fp_regnum.
>> v;int;deprecated_fp_regnum;;;-1;-1;;0
>>
>> -M;CORE_ADDR;push_dummy_call;struct value *function, struct regcache *regcache, CORE_ADDR bp_addr, int nargs, struct value **args, CORE_ADDR sp, int struct_return, CORE_ADDR struct_addr;function, regcache, bp_addr, nargs, args, sp, struct_return, struct_addr
>> +M;CORE_ADDR;push_dummy_call;struct value *function, struct regcache *regcache, CORE_ADDR bp_addr, int nargs, struct value **args, CORE_ADDR sp, int struct_return, int lang_struct_return, CORE_ADDR struct_addr;function, regcache, bp_addr, nargs, args, sp, struct_return, lang_struct_return, struct_addr
>> v;int;call_dummy_location;;;;AT_ENTRY_POINT;;0
>> M;CORE_ADDR;push_dummy_code;CORE_ADDR sp, CORE_ADDR funaddr, struct value **args, int nargs, struct type *value_type, CORE_ADDR *real_pc, CORE_ADDR *bp_addr, struct regcache *regcache;sp, funaddr, args, nargs, value_type, real_pc, bp_addr, regcache
>>
>
> No documentation, no goddie. What does the new parameter
> mean?
>
> I'd think that a bool instead of an int would be better.
> Or clearer still, an enum, like:
>
> enum class return_how { STRUCT, NORMAL };
>
> If you want to do a preparatory patch adding the enum and
> renaming "struct_return", it'd be awesome, I think.
I considered doing this but didn’t want to add a global enum to gdbarch.h
for just a single use. Agreed it is cleaner. I’ll fix it up for v3.
>
> But I suppose that given the existence of the "int struct_return"
> parameter, I can't really complain. We could always add such
> an enum later on and change both parameters at the same time
> throughout.
>
> So feel free to leave it be as is.
>
> Thanks,
> Pedro Alves
next prev parent reply other threads:[~2018-10-10 11:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-01 15:53 [PATCH v2 0/2] Aarch64: Fix segfault when casting dummy calls Alan Hayward
2018-10-01 15:53 ` [PATCH v2 1/2] Add lang_struct_return to _push_dummy_call Alan Hayward
2018-10-09 16:14 ` Pedro Alves
2018-10-10 11:54 ` Alan Hayward [this message]
2018-10-01 15:53 ` [PATCH v2 2/2] Aarch64: Fix segfault when casting dummy calls Alan Hayward
2018-10-09 16:15 ` Pedro Alves
2018-10-09 8:26 ` [PING][PATCH v2 0/2] " Alan Hayward
2018-10-09 16:10 ` [PATCH " Pedro Alves
2018-10-09 17:50 ` Alan Hayward
2018-10-10 8:23 ` Pedro Alves
2018-10-10 11:54 ` Alan Hayward
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=C1091CDD-98C6-4561-B654-130BFA5194A7@arm.com \
--to=alan.hayward@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=nd@arm.com \
--cc=palves@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).