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

[Luis Machado <lgustavo@codesourcery.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