From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] Need post-processing of parameters for function calls in Ada
Date: Tue, 08 Jan 2008 15:29:00 -0000 [thread overview]
Message-ID: <20080108152900.GB11650@adacore.com> (raw)
In-Reply-To: <20080108150114.GA19378@caradoc.them.org>
Thanks muchly for the quick feedback!
> Is this an argument coercion? The right place may be
> value_arg_coerce.
Indeed. It looks like the two functions are doing the same thing,
but for different languages.
> If the only problem is that you need the sp, we
> could supply it to that function and move the coercion after the stack
> frame setup. I don't think this will be a problem even if we need a
> function call during argument coercion.
(funny that you're talking about function call during argument coercion,
that will be my next patch which I just finished ;-).
I don't think we'll need to move the argument coercion phase...
> This might allow a useful option, to avoid calling malloc when passing
> strings to a C function. We can not do that in general, since the
> function might save the pointer, but there are some cases (like strcmp).
... unless that is needed to allow calling malloc. But this can be
discussed independently, if you prefer.
> Really this sort of thing ought to go through the language vector, but
> I'm happy leaving that until a second language needs it.
I agree. I propose the following:
- Add a new la_value_arg_coerce method in the language vector.
The prototype would be identical to the current value_arg_coerce
but with the added SP.
- rename value_arg_coerce c_value_arg_coerce. Possibly move it to
c-lang.
- Make all languages use c_value_arg_coerce, except for Ada, which
would use our own coerce routine.
That should take care of everything (except maybe allowing malloc
calls).
My only concern is that the Ada coerce might be relying on the C coerce
routine to handle the simple cases. So I might need to call the C coerce
routine at the end of the Ada coerce routine. I need to look deeper
into this.
What do you think?
Thanks,
--
Joel
next prev parent reply other threads:[~2008-01-08 15:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 14:37 Joel Brobecker
2008-01-08 15:02 ` Daniel Jacobowitz
2008-01-08 15:29 ` Joel Brobecker [this message]
2008-01-08 15:37 ` Daniel Jacobowitz
2008-01-08 15:50 ` Joel Brobecker
2008-01-08 15:57 ` Daniel Jacobowitz
2008-01-08 16:14 ` Joel Brobecker
2008-01-08 16:19 ` Daniel Jacobowitz
2008-01-08 18:53 ` [RFA] Fix parameter coercing for Ada function calls (take 2) Joel Brobecker
2008-01-08 18:56 ` Daniel Jacobowitz
2008-01-08 19:34 ` Joel Brobecker
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=20080108152900.GB11650@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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