So this is an odd bug to reproduce.
As part of integrating extra debug commands into the Linux Kernel, we created an lx-version command. It's simple enough and just finds, and displays the version string from the kernel.
However, if you run a backtrace, before you use the python lx-version command, then the string returned prints only one character.
It actually has a strlen of 0 - but I traced through the gdb.Value code, and found that somewhere it gets +1 added to it, which means it prints just one char.
#0 cpu_v7_do_idle () at .../linux/arch/arm/mm/proc-v7.S:74
#1 0xc0308728 in arch_cpu_idle () at .../linux/arch/arm/kernel/process.c:72
#2 0xc0376b28 in cpuidle_idle_call () at .../linux/kernel/sched/idle.c:151
#3 cpu_idle_loop () at .../linux/kernel/sched/idle.c:242
#4 cpu_startup_entry (state=<optimized out>) at .../linux/kernel/sched/idle.c:291
#5 0xc0ae8a30 in rest_init () at .../linux/init/main.c:408
#6 0xc0f00c5c in start_kernel () at .../linux/init/main.c:661
#7 0x8020807c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
L(gdb) print linux_banner #### Note the 'L' at the beginning of the line ####
$1 = 0xc0b00074 <linux_banner> "Linux version 4.6.0-rc1 (kbingham@CookieMonster) (gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu1) ) #13 SMP Thu Mar 31 10:33:19 BST 2016\n"
(gdb) print &linux_banner
$2 = (const char (*)) 0xc0b00074 <linux_banner>
If however, upon connecting to the target, you run 'lx-version', *then* 'bt', both operate as expected.
Perhaps the string / value gets cached somewhere?
/me is puzzled :D
Did you ever find out what's going on?
No we never did quite get to the bottom of this.
I'm afraid I'm on honeymoon now so apologies for the delays, I'll find you on IRC when I'm back and we can see what we can do to get this resolved or at least understand the root cause.
I just entered this bug in the Linaro GDB bugzilla, in the hope that somebody in the Linaro toolchain working group will have some time to debug this issue.
Unfortunately I haven't had time to debug it further, as I'm busy trying to prepare the linux-kthread GDB patches to send to the ML.
Does this still happen?
It's a long time since I've tried this.
I'll try to see if I can recreate this issue this week.
Please ping me, either here or on IRC if it slips my radar.
So I've been sent a patch that simply adds a cast to the string pointer here, to workaround this issue.
In the patch - the submitter describes this issue as only happening on GBD 7.3 and below.
I'm afraid I haven't been able to find time to replicate this issue again yet. But if it's not causing problems in mainline GDB then I don't think there's much action to take.
We'll likely apply the cast patch to the linux kernel command to support older versions if it works. It should be 'forwards' compatible.
So this issue is still present in mainline GDB.
The following thread  shows the workaround which will handle this for us. But the bug might still be interesting for someone to investigate: