This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH, c++ testsuite] Fix a few failures in gdb.cp/virtfunc.exp
- From: Will Newton <will dot newton at linaro dot org>
- To: lgustavo at codesourcery dot com
- Cc: Tom Tromey <tromey at redhat dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 4 Jun 2013 10:10:45 +0100
- Subject: Re: [PATCH, c++ testsuite] Fix a few failures in gdb.cp/virtfunc.exp
- References: <51AC8CA2 dot 3030008 at codesourcery dot com> <87vc5vmamh dot fsf at fleche dot redhat dot com> <51ADAAEC dot 6020902 at codesourcery dot com> <51ADAD62 dot 6060704 at codesourcery dot com>
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.
--
Will Newton
Toolchain Working Group, Linaro