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] |
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] |