RE: [PATCH] btrace: avoid tp != NULL assertion

["Metzger, Markus T" <markus.t.metzger@intel.com>]

> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Tuesday, March 3, 2015 4:25 PM
> To: Metzger, Markus T
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH] btrace: avoid tp != NULL assertion


> >>>>> No, that wasn't the reason for replacing the assert.  There are no such
> >>>>> errors in the gdb.btrace suite (which is mostly single-threaded) with
> my
> >>>>> patch and I have not seen any such errors otherwise, either.
> >>>>
> >>>> Then it sounds like we're either lacking basic tests, or the threaded
> tests
> >>>> are somehow not running correctly when gdb is a 32-bit program.  I
> think
> >>>> that if you step any non-leader thread, you should see it happen.
> >>>> Grepping the tests, I think gdb.btrace/multi-thread-step.exp should
> have
> >>>> caught it.  My machine doesn't do btrace, so I can't try it myself...
> >>>>
> >>>> BTW, did any existing test in the testsuite catch the assertion we're
> >>>> fixing?
> >>>
> >>> Almost all of them when run on 32-bit systems; -m32 on 64-bit systems
> >> does
> >>> not catch this.
> >>
> >> Right, that's why I said "when gdb is a 32-bit program".  Sounds like
> >> no existing test tries a "step" when not replaying then.  It'd be very
> >> nice to have one.  Can I convince you to add one?  :-)
> >
> > The multi-thread-step.exp test does not catch it because it uses "cont",
> > which works fine.  When I add a "step" before the "cont", I get the
> > "No thread" error when using my old patch instead of your new patch.
> > Or I get the assert when using neither my old nor your new patch.
> > But then, I got the assert already on other tests.
> >
> > With my patch dropped and your patch committed, what is the new
> > test expected to catch?
> 
> You're getting me confused...
> 
> The test was expected to catch the assertion, given that apparently
> no other test was catching it -- from the dialog above, one understands
> no test would be catching this before (that's what I explicitly
> asked), but now you're saying the opposite.

I think that was a misunderstanding.  The assertion is caught by several
gdb.btrace tests when run with 32-bit GDB.

I thought you were referring to the badness in my patch that would
result in GDB asking for registers in a wrong process.

Regards,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052