Did you ever find out what's going on?

Hi Pedro,

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.

Hi,

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.

Pete.

Does this still happen?

Hi Tom,

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.
--
Kieran

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.

https://lore.kernel.org/lkml/20181017023652.6867-1-changbin.du@gmail.com/t/#u

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 [0] shows the workaround which will handle this for us. But the bug might still be interesting for someone to investigate: 

[0] https://lkml.org/lkml/2018/10/17/798

There are 2 different declarations of the linux_banner variable:

https://github.com/torvalds/linux/blob/master/init/version.c#L50:

const char linux_banner[] __weak;

https://github.com/torvalds/linux/blob/master/init/version-timestamp.c#L28-L30:

const char linux_banner[] =
	"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
	LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";


We can try this ourselves with this reproducer:

main.c:
```

int part1();
int part2();

int main()
{
  int sum = part1();
  sum += part2();
  return sum;
}
```

part1.c:
```

const char linux_banner[] __attribute__((weak));

int part1()
{
  return 1;
}
```

part2.c:
```

const char linux_banner[] = "Linux version 1.2.3.4";

int part2()
{
  return 2;
}
```

$ gcc -g -o example main.c part1.c part2.c


Depending on the declaration that was last 'used', this gives different results.

With a breakpoint in part1.c with the weak declaration:
```
$ gdb -q example.exe
Reading symbols from example.exe...
(gdb) b part1
Breakpoint 1 at 0x140001634: file part1.c, line 6, column 10.
(gdb) b 9
Breakpoint 2 at 0x14000161d: file main.c, line 9, column 10.
(gdb) r
Starting program: C:\src\tests\example.exe

Breakpoint 1, part1 () at part1.c:6
6         return 1;
                 ^
(gdb) c
Continuing.

Breakpoint 2, main () at main.c:9
9         return sum;
                 ^
(gdb) py print(repr(gdb.parse_and_eval("linux_banner").string()))
''
(gdb) pt linux_banner
type = const char []
```


With a breakpoint in part2.c with the full declaration:
```
$ gdb -q example.exe
Reading symbols from example.exe...
(gdb) b part2
Breakpoint 1 at 0x140001644: file part2.c, line 6, column 10.
(gdb) b 9
Breakpoint 2 at 0x14000161d: file main.c, line 9, column 10.
(gdb) r
Starting program: C:\src\tests\example.exe

Breakpoint 1, part2 () at part2.c:6
6         return 2;
                 ^
(gdb) c
Continuing.

Breakpoint 2, main () at main.c:9
9         return sum;
                 ^
(gdb) py print(repr(gdb.parse_and_eval("linux_banner").string()))
'Linux version 1.2.3.4'
(gdb) pt linux_banner
type = const char [22]
```