RE: [PATCH] btrace, vdso: add vdso target sections

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

> -----Original Message-----
> From: Metzger, Markus T
> Sent: Monday, May 19, 2014 10:06 AM


> > > +# trace the test code
> > > +gdb_test_no_output "record btrace"
> > > +gdb_test "next"
> >
> > Please add a pattern that makes sure the "next" actually
> > finished successfully.

There's another problem that showed when I added such a
pattern for the "reverse-stepi" command.

The command prints "Cannot access memory at address 0x4004b0".
The error occurs during frame unwind when we try to
disassemble an instruction in order to get its length.

The problem is that the GDB memory cache may turn reads from
one section into reads from a different section or from memory
regions outside of any section.

The address, 0x4004b0 is the first entry in .plt, a read-only code
section.  The disassembler tries to read 1 byte from this address.
The memory cache turns this into a request for 64 bytes from
0x400480, which lies in a different section, .rela.plt in my case.

The read still succeeds in my example since the other section is
also readonly, but there's no guarantee for this.

The memory read passes through record_btrace_xfer_partial
which reduces the length to fit into a single section, so the target's
read memory function tries to read the remainder of the cache line.

This eventually fails since the cache line contains a memory region
that is not contained in any section and record_btrace_xfer_partial
returns TARGET_XFER_UNAVAILABLE.


I would argue that the memory cache should not extend the original
read request beyond section boundaries.  What do you think?

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