This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unwind, x86, DW_CFA_GNU_args_size


Geoffrey Keating <geoffk@apple.com> writes:

> On 18/08/2006, at 5:42 PM, Ian Lance Taylor wrote:
> 
> ...
> > We could change CSA so that when it combines a prologue instruction
> > with a non-prologue instruction it sets a new flag on the instruction,
> > and uses a table on the side to record the original values in the
> > instruction.
> 
> I guess that would work; but wouldn't it be easier to just have
> calls.c tell the dwarf output code what the right offset is?

Would that actually work correctly when the stack adjustments are
combined?  Wouldn't we get the wrong number when different stack
adjustments were combined?

> > We could avoid nesting memcpy calls on ACCUMULATE_OUTGOING_ARGS
> > machines, in which case I think Alex's patch is unnecessary.
> >
> > I'm not sure about your option 1--Alex didn't say that he couldn't
> > reproduce the bug in mainline, he said he didn't have a test case for
> > the specific case of memcpy popping the arguments off the stack on
> > return.
> 
> I'm not sure how memcpy gets involved here.  memcpy doesn't throw, so
> there's no need for any args_size data for it---in fact, it's a small
> optimization bug that such data gets reflected in the EH information
> at all.
> 
> Alex said that he couldn't find a case that didn't involve memcpy.
> Maybe an appropriate 'fix' is to revert the patch and put an assert
> in calls.c to ensure that a nested function call must be nothrow?

That seems quite plausible to me.  Alex?

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]