Re: [PATCH, c++ testsuite] Fix a few failures in gdb.cp/virtfunc.exp

[Luis Machado <lgustavo at codesourcery dot com>]

On 06/04/2013 11:10 AM, Will Newton wrote:
> On 4 June 2013 10:03, Luis Machado <lgustavo@codesourcery.com> wrote:
> > On 06/04/2013 10:53 AM, Luis Machado wrote:
> > > On 06/03/2013 06:17 PM, Tom Tromey wrote:
> > > > > > > > > "Luis" == Luis Machado <lgustavo@codesourcery.com> writes:
> > > >
> > > >
> > > > Luis> 2013-06-03  Luis Machado  <lgustavo@codesourcery.com>
> > > > Luis>     * gdb.cp/virtfunc.exp (make_one_vtable_result): Handle extra
> > > > output
> > > > Luis>     from targets that use function descriptors in the virtual
> > > > tables.
> > > >
> > > > Ok.  Thanks for looking at this.
> > >
> > >
> > > Before checking in the patch, i figured out the rest of the problems.
> > >
> > > Newer GDB's seem to have fixed a problem with displaying thunks in the
> > > virtual tables. Older ones did not demangle those names properly.
> > >
> > > With that said, ppc64 uses dot symbols for those thunks, so we need to
> > > account for those in the testcase as well.
> > >
> > > Here's the updated patch. I escaped dot once (\.) instead of twice. So
> > > hopefully this is the correct way. I often get confused with escaping in
> > > dejagnu.
> > >
> > > With this fix, i see only a single failure for virtfunc.exp on ppc64.
> > > The other failure is more involved and i'm still chasing the root cause.
> >
> >
> > For convenience, here is an example of how the output looks for ppc64. Thunk
> > symbols have a dot prefix.
> >
> > vtable for 'D' @ 0x10013248 (subobject @ 0x10013ed0):
> > [0]: @0x10013c00: 0x10001d64 <.non-virtual thunk to E::vg()>
> > [1]: @0x10013ca8: 0x10001eec <D::vd()>
> >
> > vtable for 'V' @ 0x10013290 (subobject @ 0x10013ef0):
> > [0]: @0x10013cd8: 0x10001f74 <VB::vvb()>
> > [1]: @0x10013c60: 0x10001e38 <.virtual thunk to E::vv()>
>
> ARM also has a similar problem, as Thumb addresses end up looking like:
>
> [0]: 0x8e7d <non-virtual thunk to E::vg()+1>
>
> I'm not sure if it's a problem with the test or if there is a missing
> call to addr_bits_remove somewhere.

Hum. I'd double check printcmd.c:build_address_symbolic to make sure it 
is doing the right thing.

I think E::vg(), E::vg()+2, E::vg()+3 is what should be displayed, correct?

Luis