RE: [PATCH 00/16] branch tracing support (resend)

["Metzger, Markus T" <markus dot t dot metzger at intel dot com>]

> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Wednesday, May 30, 2012 7:56 PM
> To: Metzger, Markus T


> > The first hundred iterations are looking good on my system.
>
>
> In that case,
>
> > I'm using 2.6.32-220.el6.x86_64, this time.
> > I'll let this run overnight
>
>
> that is probably unnecessary -- I get failures in almost every run, but the
> set of tests that fail changes between runs.

I get sporadic fails about every 1000th run. Most occur when switching 
threads, i.e.

	gdb_test "thread 2" ".*Switching to thread 2.*"

I got two timeouts while switching threads, as well.


> Attached two gdb.log files, of different runs showing different failures.

In the files you sent me, we do not get the full trace sometimes.

This might be related to a Linux perf_event feature. The perf_event consumer
is responsible for detecting when there are new records. The tracee is 
scheduled
out after it notified its ptracer. When it is scheduled out, it may write a 
few more
trace records. The ptracer may already be running, at this time.

In gdb/common/linux-btrace.c, I check for new data after I finished reading 
the
trace, and start over again when I see new records. This was meant to mitigate 
this.
Until now, I thought that this would be sufficient. In general, however, there 
is no
guarantee that we will not get new trace records after we finished reading.

For interactive debugger use, this should not be a problem. There is plenty of 
time
for the debuggee to write its last trace records before we start reading the 
trace.
For scripting, however, it seems that we may indeed be too fast sometimes.

I don't have a solution for this. Ideally, the kernel would write branch trace 
records
before notifying the ptracer. Or it would allow access to the actual trace 
buffer given
to the hardware (which would avoid the write-back problem). In gdb, we could 
yield
when reading branch trace to increase the chance that the debuggee finished 
writing.
Or we simply accept this behavior as a strange curiosity.

Regards,
Markus.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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