Re: [PING] [PATCH] gdb/arm: Fix backtrace for pthread_cond_timedwait

[Luis Machado <luis.machado@arm.com>]

Hi Jan,

On 1/18/23 11:51, Jan Kratochvil wrote:
> Hi Luis,
> 
> On Tue, 17 Jan 2023 19:14:01 +0800, Luis Machado wrote:
>> I see the same results with a patched and unpatched gdb:
>>
>> PASS: gdb.arch/arm-pthread_cond_timedwait-bt.exp: successfully compiled posix threads test case
>> PASS: gdb.arch/arm-pthread_cond_timedwait-bt.exp: advance to break-line
>> PASS: gdb.arch/arm-pthread_cond_timedwait-bt.exp: thread 2 for svc check
>> UNTESTED: gdb.arch/arm-pthread_cond_timedwait-bt.exp: pc points to svc
>>
>> Do you see something different?
> 
> Yes, on Raspbian 11 (bullseye), Linux version 5.15.32-v7l+, Raspberry 4.
> 
> What OS do you run?

I'm on Ubuntu 22.04/20.04, but running 32-bit on a 64-bit system via Docker. There seems to be a divergence in the
expected pattern of the svc instruction.

I see the following:

x/i $pc
=> 0xf7eadb04 <__libc_do_syscall+4>:    svc     0

The test seems to be expecting a pattern of

x/i $pc
=> 0xf7eadb04 <__libc_do_syscall+4>:    svc     0x00000000

If I replaced the pattern to force a match, the test continues until the unwinder check. Then it runs into a
UNTESTED again because I see the dwarf2 unwinder being used.

That may be because I have debug info installed I suppose. I wonder if there is a way to force gdb not to use the
dwarf2 unwinder for libc, even if it is available on the system.

> 
> There is the unfortunate dependency on system pthread_cond_timedwait()
> implementation. The testcase could provide also its own .S implementation but
> then it could be incompatible with the rest of system glibc.
> 
> 
> Jan