This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB 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: [PATCH] Fixes testsuit/gdb.base/annota1.exp


Andrew,

(I am sorry if this is just a rehash of the past, but it's new to me :-)

On Wednesday 22 September 2004 12:51, Andrew Cagney wrote:

--- snip ---
> > The problem is specific to any ISA that uses delayed breakpoints...  I
> > think that's just the Power64.
>
> Keep going .... what problem?
>

The problem of backtracing past main.  It shows up when debugging a 64-bit 
application.  it does NOT show up when debugging a 32-bit application.  Both 
on powerpc64--linux.

> >>> I see this lets GDB accept the ``warning: adjusting breakpoint''
> >>> message.  I'm wondering if GDB should even emit the warning - it and
> >>> the descriptor are very much integral parts of the ABI - and hence
> >>> should be trying to always display the descriptor symbol and code
> >>> address (and not display the dot symbol).
> >
> > I think I agree.  Unless this level of detail is needed by the user for
> > some reason.  And I don't think they need to be reminded every time the
> > breakpoint is hit.  But that's the way the code is.  The testsuite should
> > reflect the way the code is, and to a certain extent, the way it was.
> >
> >>> What's going to happen when 64-bit PPC stops emiting those dot symbols?
> >
> > When this happens, then the regexp that I added would never be matched. 
> > So Its kind of self correcting.
>
> This sounds like a KFAIL.
>
>  > Some time later we can just remove the regexp.
>
> (that never happens)
>
> >>>> > 2) Due to a bug (I which I knew the number), GDB 'skids' past the
> >>>> > top-of-stack when doing a backtrace.  This causes two extra and
> >>>> > severial garbage stack frames to be displayed, eventually getting an
> >>>> > error.
> >>>
> >>> You mean backtracing past main - that code was recently rewritten.
> >>> However, there's apparently no test case for the feature, perhaphs it
> >>> it should first be added and fixed?.  Anyway, I don't think we should
> >>> be passing a broken backtrace.
> >
> > Well... this doesn't 'pass' a broken backtrace, it just doesn't let a
> > broken backtrace stop it from testing what it is really interested in:
> > annotations.
>
> That sounds like a KFAIL.

So when testing annotations, it will be a known failure on powerpc64--linux, 
when debugging a 64-bit application, because backtrace went past main.

I agree it is a known failure.  But it has nothing to do with annotations.  
Annotations work fine.  

I can see what a mess we would have if each test started trying to defend its 
self against bugs outside of the area being tested.

It it well known that a 'KFAIL' durring a test may have nothing to do with 
what is being tested? 

Is there an equivelent failure for 'I just can't run this part of the test?'

>
> > I agree that we need a test for the 'backtracing past main' problem.  I
> > will post one later today, along with a log showing it in action.  Which
> > .exp file would you suggest I use as a model?
>
> The first half of siginfo.*?
>
> Andrew

OK, so I wrote a test for the 'backtracing past main' problem.  Here it is 
along with a couple of logs:

Attachment: backtrace.exp
Description: Text document

Attachment: gdb.log.64
Description: Text document

Attachment: gdb.log.32
Description: Text document


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