Unreasonable expectation in gdb.base/break.exp

Unreasonable expectation in gdb.base/break.exp

[David S. Miller]

When compiled with optimizations enabled, this testcase
expects that stopping at main() will result in the place
being somewhere within the source file of main().

This is not necessarily the case.

In my case on sparc-*-linux*, the instruction that starts
main() in this situation is part of the inline expansion of
strtol(), via the inline expansion of atoi(), in the
stdlib.h header file so that is the place GDB reports that
it is at when the breakpoint on main() is hit.

This causes the break.exp testcase to fail.

I think this is perfectly reasonable and correct behavior on
both gdb's and gcc's part, and this check in break.exp should
be made a little bit more leanient.

Any objections?

Re: Unreasonable expectation in gdb.base/break.exp

[Daniel Jacobowitz]

On Tue, Apr 04, 2006 at 04:02:27PM -0700, David S. Miller wrote:
> I think this is perfectly reasonable and correct behavior on
> both gdb's and gcc's part, and this check in break.exp should
> be made a little bit more leanient.
> 
> Any objections?

That seems reasonable to me, but what do you propose testing for
instead?  I suppose if we don't check the source file, we'll still be
able to check the function name when we hit the breakpoint.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Unreasonable expectation in gdb.base/break.exp

[David S. Miller]

From: Daniel Jacobowitz <drow@false.org>
Date: Tue, 4 Apr 2006 19:05:35 -0400

> On Tue, Apr 04, 2006 at 04:02:27PM -0700, David S. Miller wrote:
> > I think this is perfectly reasonable and correct behavior on
> > both gdb's and gcc's part, and this check in break.exp should
> > be made a little bit more leanient.
> > 
> > Any objections?
> 
> That seems reasonable to me, but what do you propose testing for
> instead?  I suppose if we don't check the source file, we'll still be
> able to check the function name when we hit the breakpoint.

The function name will be the inline function name, because
that is the function we will be "in", not main().  And that
could basically be anything.

Once you have inlining and optimizations enabled, this particular
check loses it's sense.

Re: Unreasonable expectation in gdb.base/break.exp

[Daniel Jacobowitz]

On Tue, Apr 04, 2006 at 04:09:01PM -0700, David S. Miller wrote:
> The function name will be the inline function name, because
> that is the function we will be "in", not main().  And that
> could basically be anything.

Well, no, it shouldn't be.  It should be some day, but for the moment,
gdb will report that you're in main no matter what's been inlined into
it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Unreasonable expectation in gdb.base/break.exp

[David S. Miller]

From: Daniel Jacobowitz <drow@false.org>
Date: Tue, 4 Apr 2006 19:12:25 -0400

> On Tue, Apr 04, 2006 at 04:09:01PM -0700, David S. Miller wrote:
> > The function name will be the inline function name, because
> > that is the function we will be "in", not main().  And that
> > could basically be anything.
> 
> Well, no, it shouldn't be.  It should be some day, but for the moment,
> gdb will report that you're in main no matter what's been inlined into
> it.

Indeed, you are right.  I just rechecked exactly what happens
and it does report "main ( ... ) at stdlib.h:333"

So do you agree to change the check to just verify that we are
in fact in main()?

Thanks.

Re: Unreasonable expectation in gdb.base/break.exp

[Daniel Jacobowitz]

On Tue, Apr 04, 2006 at 04:20:52PM -0700, David S. Miller wrote:
> From: Daniel Jacobowitz <drow@false.org>
> Date: Tue, 4 Apr 2006 19:12:25 -0400
> 
> > On Tue, Apr 04, 2006 at 04:09:01PM -0700, David S. Miller wrote:
> > > The function name will be the inline function name, because
> > > that is the function we will be "in", not main().  And that
> > > could basically be anything.
> > 
> > Well, no, it shouldn't be.  It should be some day, but for the moment,
> > gdb will report that you're in main no matter what's been inlined into
> > it.
> 
> Indeed, you are right.  I just rechecked exactly what happens
> and it does report "main ( ... ) at stdlib.h:333"
> 
> So do you agree to change the check to just verify that we are
> in fact in main()?

Yes, I think so.  I've had this failure in different compilers before.

Eventually, we'll have to relax the name check too, when we start
reporting inlined functions properly.  But no one is working on that
right now; I had some patches to do it, but they were very buggy.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Unreasonable expectation in gdb.base/break.exp

[David S. Miller]

From: Daniel Jacobowitz <drow@false.org>
Date: Tue, 4 Apr 2006 21:37:09 -0400

> On Tue, Apr 04, 2006 at 04:20:52PM -0700, David S. Miller wrote:
> > So do you agree to change the check to just verify that we are
> > in fact in main()?
> 
> Yes, I think so.  I've had this failure in different compilers before.
> 
> Eventually, we'll have to relax the name check too, when we start
> reporting inlined functions properly.  But no one is working on that
> right now; I had some patches to do it, but they were very buggy.

Ok, I'll cook up a patch that does this.

Thanks.