Re: [PATCH V2] gdb: Upgrade 16.3 -> 17.1

["Dora, Sunil Kumar" <SunilKumar.Dora@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

Hi Mathieu,

Thanks for reporting this.

This appears to be an upstream GDB issue affecting musl builds. The failure comes from set_custom_baudrate_linux() in gdb/ser-unix.c , which directly accesses struct termios members c_ospeed / c_ispeed. These fields exist with those names in glibc, but musl exposes them as __c_ospeed / __c_ispeed , which explains the build breakage you’re seeing.

There is an upstream Bugzilla report tracking this issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=33747

I’ve been participating in the discussion there and shared some investigation and a possible direction, but there is *no agreed-upon fix yet*. A few important points from the upstream discussion so far:

* 

Simply switching to cfset [io] speed() is not sufficient in all cases, since musl rejects non-standard baud rates and the existing GDB code intentionally bypasses that API.

* 

Using libc-specific field names via #ifdef is fragile.

* 

One possible approach under discussion is using a Linux termios2 -based path guarded by TCGETS2 , but this needs careful handling (e.g. BOTHER values differ across architectures).

Given this, it seems best to let this get resolved upstream rather than adding a temporary OE-Core workaround. I’ll keep an eye on the upstream bug and follow up once there’s either a merged fix or a clearly recommended approach we can backport.

Thanks,
Sunil

[-- Attachment #2: Type: text/html, Size: 2687 bytes --]