This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/4] New gdb arch hook: return_with_first_hidden_param_p
- From: Gary Benson <gbenson at redhat dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: yao at codesourcery dot com, brobecker at adacore dot com, gdb-patches at sourceware dot org, cltang at codesourcery dot com
- Date: Fri, 6 Jul 2012 14:17:03 +0100
- Subject: Re: [PATCH 1/4] New gdb arch hook: return_with_first_hidden_param_p
- References: <4FA22D7B.1040707@codesourcery.com> <20120504175830.GQ15555@adacore.com> <4FA743EC.1080903@codesourcery.com> <20120507201345.GX15555@adacore.com> <4FAA2D25.4060700@codesourcery.com> <20120510212054.GA5886@adacore.com> <4FACEB4B.1060603@codesourcery.com> <20120514171453.GL10253@adacore.com> <4FB1FCD2.5070302@codesourcery.com> <201205151802.q4FI2O2Y013475@glazunov.sibelius.xs4all.nl>
Hi Mark,
Sorry for replying to this so late, I've been on leave with a new
baby!
Mark Kettenis wrote:
> > Date: Tue, 15 May 2012 14:50:58 +0800
> > From: Yao Qi <yao@codesourcery.com>
> >
> > On 05/15/2012 01:14 AM, Joel Brobecker wrote:
> > > > > > > Can we use the fact that functions that have their first
> > > > > > > parameter be a nameless, artificial, paramter whose type
> > > > > > > is a pointer to the return type? Or would this
> > > > > > > heuristics trigger in other situations?
> > > > >
> > > > > Yeah, I thought of that heuristics, but it still can't
> > > > > differentiate passing 3 or 4 parameters.
> > >
> > > So, you are saying that we have functions who have an extra
> > > hidden parameter used for something other than the function's
> > > return value?
> >
> > No, the extra hidden parameter's type is the reference of the
> > function's return type. My point is if we only examine debug
> > info, we don't know whether hidden parameter is passed, because
> > the debug info is the same regardless of hidden parameter is
> > passed or not.
>
> I'm still very confused. This "hidden parameter" thing sounds
> exactly like "struct_return". So are you saying that on some
> architectures gdbarch_return_value() return
> RETUN_VALUE_REGISTER_CONVENTION when if fact for C++ (and not for
> plain C) it should return RETURN_VALUE_STRUCT_CONVENTION?
I've been investigating a bug which looks like this might be
happening:
http://sourceware.org/bugzilla/show_bug.cgi?id=13403
I meant to email you about it before I went on leave, I was struggling
to match what it says in the comments with what I was reading in the
spec.
I don't have anything particular to say right now--I'm still trying to
figure out where I was--but I'm replying now just to let you know that
there may be an issue here. I'll hopefully have something more useful
to say next week :)
Thanks,
Gary
--
http://gbenson.net/