[PATCH] gdb/ser-unix: avoid musl build failure when setting custom baud rates

[PATCH] gdb/ser-unix: avoid musl build failure when setting custom baud rates

[sunilkumar.dora]

From: Sunil Dora <sunilkumar.dora@windriver.com>

GDB's Linux custom baud rate implementation accessed the non-standard
struct termios members c_ispeed and c_ospeed directly. These members
are provided by glibc but are not exposed by musl, causing the build
to fail with errors such as:

  error: no member named 'c_ospeed' in 'termios'
  error: no member named 'c_ispeed' in 'termios'

Musl follows strict POSIX semantics and does not expose these
implementation-specific fields. In addition, cfsetospeed/cfsetispeed
may reject non-standard baud rates, and the Linux-specific termios2
interface is not always available through musl libc headers.

Refactor set_custom_baudrate_linux to use a layered approach:

  1. Attempt to use cfsetospeed/cfsetispeed
  2. Attempt to use the Linux termios2 interface (TCGETS2/TCSETS2)
     when available.
  3. Fall back to direct struct termios field access only when the
     required fields are exposed by the libc.

If none of these mechanisms succeed, report an error.

This preserves existing behavior on glibc systems while avoiding
build failures on musl-based systems.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33747

* gdb/ser-unix.c (set_custom_baudrate_linux): Refactor custom
  baud rate handling to avoid unconditional use of non-standard
  termios members.

Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
---
 gdb/ser-unix.c | 68 ++++++++++++++++++++++++++++++++++++--------------
 1 file changed, 49 insertions(+), 19 deletions(-)

diff --git a/gdb/ser-unix.c b/gdb/ser-unix.c
index c295a9c5ba1..571a59ab280 100644
--- a/gdb/ser-unix.c
+++ b/gdb/ser-unix.c
@@ -515,31 +515,61 @@ set_baudcode_baudrate (struct serial *scb, int baud_code)
 static void
 set_custom_baudrate_linux (int fd, int rate)
 {
-#ifdef TCGETS2
-  struct termios2 tio;
-  const unsigned long req_get = TCGETS2;
-  const unsigned long req_set = TCSETS2;
-#else
+  /* Standard POSIX API  */
+#if defined (_HAVE_STRUCT_TERMIOS_C_OSPEED) \
+    || defined (_HAVE_STRUCT_TERMIOS_C_ISPEED)
   struct termios tio;
-  const unsigned long req_get = TCGETS;
-  const unsigned long req_set = TCSETS;
+  if (ioctl (fd, TCGETS, &tio) == 0)
+    {
+      if (cfsetospeed (&tio, rate) == 0 && cfsetispeed (&tio, rate) == 0)
+	{
+	  if (ioctl (fd, TCSETS, &tio) == 0)
+	    return;
+	}
+    }
 #endif
 
-  if (ioctl (fd, req_get, &tio) < 0)
-    perror_with_name (_("Can not get current baud rate"));
+  /* Linux Kernel 'termios2' API (Linux/Musl).
+     This allows arbitrary baud rates (e.g., 25000).  */
+#ifdef TCGETS2
+  struct termios2 tio2;
+
+  if (ioctl (fd, TCGETS2, &tio2) == 0)
+    {
+      tio2.c_cflag &= ~CBAUD;
+      tio2.c_cflag |= BOTHER;
+      tio2.c_ospeed = rate;
 
-  /* Clear the current output baud rate and fill a new value.  */
-  tio.c_cflag &= ~CBAUD;
-  tio.c_cflag |= BOTHER;
-  tio.c_ospeed = rate;
+      tio2.c_cflag &= ~(CBAUD << IBSHIFT);
+      tio2.c_cflag |= BOTHER << IBSHIFT;
+      tio2.c_ispeed = rate;
 
-  /* Clear the current input baud rate and fill a new value.  */
-  tio.c_cflag &= ~(CBAUD << IBSHIFT);
-  tio.c_cflag |= BOTHER << IBSHIFT;
-  tio.c_ispeed = rate;
+      if (ioctl (fd, TCSETS2, &tio2) == 0)
+	return;
+    }
+#endif
 
-  if (ioctl (fd, req_set, &tio) < 0)
-    perror_with_name (_("Can not set custom baud rate"));
+ /* Legacy Fallback.
+    We only try this if the libc actually supports the fields we need.
+    On Musl, this block is correctly skipped.  */
+#if defined (_HAVE_STRUCT_TERMIOS_C_OSPEED)
+  struct termios tio3;
+  if (ioctl (fd, TCGETS, &tio3) == 0)
+    {
+      tio3.c_cflag &= ~CBAUD;
+      tio3.c_cflag |= BOTHER;
+      tio3.c_ospeed = rate;
+#ifdef _HAVE_STRUCT_TERMIOS_C_ISPEED
+      tio3.c_cflag &= ~(CBAUD << IBSHIFT);
+      tio3.c_cflag |= BOTHER << IBSHIFT;
+      tio3.c_ispeed = rate;
+#endif
+      if (ioctl (fd, TCSETS, &tio3) == 0)
+       return;
+    }
+#endif
+
+  perror_with_name (_ ("Can not set custom baud rate"));
 }
 
 #elif HAVE_CUSTOM_BAUDRATE_SUPPORT && defined(IOSSIOSPEED)
-- 
2.49.0

Re: [PATCH] gdb/ser-unix: avoid musl build failure when setting custom baud rates

[Kevin Buettner]

On Fri, 13 Feb 2026 07:21:51 -0800
sunilkumar.dora@windriver.com wrote:

> From: Sunil Dora <sunilkumar.dora@windriver.com>
> 
> GDB's Linux custom baud rate implementation accessed the non-standard
> struct termios members c_ispeed and c_ospeed directly. These members
> are provided by glibc but are not exposed by musl, causing the build
> to fail with errors such as:
> 
>   error: no member named 'c_ospeed' in 'termios'
>   error: no member named 'c_ispeed' in 'termios'
> 
> Musl follows strict POSIX semantics and does not expose these
> implementation-specific fields. In addition, cfsetospeed/cfsetispeed
> may reject non-standard baud rates, and the Linux-specific termios2
> interface is not always available through musl libc headers.
> 
> Refactor set_custom_baudrate_linux to use a layered approach:
> 
>   1. Attempt to use cfsetospeed/cfsetispeed
>   2. Attempt to use the Linux termios2 interface (TCGETS2/TCSETS2)
>      when available.
>   3. Fall back to direct struct termios field access only when the
>      required fields are exposed by the libc.
> 
> If none of these mechanisms succeed, report an error.
> 
> This preserves existing behavior on glibc systems while avoiding
> build failures on musl-based systems.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33747
> 
> * gdb/ser-unix.c (set_custom_baudrate_linux): Refactor custom
>   baud rate handling to avoid unconditional use of non-standard
>   termios members.
> 
> Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
> ---
>  gdb/ser-unix.c | 68 ++++++++++++++++++++++++++++++++++++--------------
>  1 file changed, 49 insertions(+), 19 deletions(-)
> 
> diff --git a/gdb/ser-unix.c b/gdb/ser-unix.c
> index c295a9c5ba1..571a59ab280 100644
> --- a/gdb/ser-unix.c
> +++ b/gdb/ser-unix.c
> @@ -515,31 +515,61 @@ set_baudcode_baudrate (struct serial *scb, int
> baud_code) static void
>  set_custom_baudrate_linux (int fd, int rate)
>  {
> -#ifdef TCGETS2
> -  struct termios2 tio;
> -  const unsigned long req_get = TCGETS2;
> -  const unsigned long req_set = TCSETS2;
> -#else
> +  /* Standard POSIX API  */
> +#if defined (_HAVE_STRUCT_TERMIOS_C_OSPEED) \
> +    || defined (_HAVE_STRUCT_TERMIOS_C_ISPEED)
>    struct termios tio;
> -  const unsigned long req_get = TCGETS;
> -  const unsigned long req_set = TCSETS;
> +  if (ioctl (fd, TCGETS, &tio) == 0)
> +    {
> +      if (cfsetospeed (&tio, rate) == 0 && cfsetispeed (&tio, rate) == 0)
> +	{
> +	  if (ioctl (fd, TCSETS, &tio) == 0)
> +	    return;
> +	}
> +    }
>  #endif

I'm concerned about a couple of things in this part of your patch:

1) I don't think it's a good idea to use _HAVE_STRUCT_TERMIOS_C_OSPEED
   and _HAVE_STRUCT_TERMIOS_C_ISPEED within GDB.  These are
   glibc-internal macros (defined in bits/termios-struct.h for glibc's
   own use in speed.c), not part of any public API.  I think that the
   right way to do this is to use some suitable autoconf feature test
   to select this code.

2) I don't think that it's correct to call cfsetospeed and cfsetispeed
   with arbitrary baud rates.  According to the man page, these
   functions expect to be passed one of the "B" constants like B1200,
   B9600, etc, not arbitrary speeds.  The existing code which uses the
   BOTHER extension is the correct way to do this.

Kevin

Re: [PATCH] gdb/ser-unix: avoid musl build failure when setting custom baud rates

[Maciej W. Rozycki]

On Fri, 13 Feb 2026, Kevin Buettner wrote:

> 2) I don't think that it's correct to call cfsetospeed and cfsetispeed
>    with arbitrary baud rates.  According to the man page, these
>    functions expect to be passed one of the "B" constants like B1200,
>    B9600, etc, not arbitrary speeds.  The existing code which uses the
>    BOTHER extension is the correct way to do this.

 FYI as from v2.42 glibc finally does support arbitrary baud rates with 
`cfsetospeed' and `cfsetispeed' with Linux as well, in addition to Hurd, 
which it has been since forever.  This is fully documented in the glibc 
manual; the man page you refer to is likely outdated.

 The BOTHER flag is the raw OS kernel interface and its direct use is 
discouraged.

 Cf. 
<https://inbox.sourceware.org/libc-alpha/20250612013546.1524096-1-hpa@zytor.com/>, 
<https://sourceware.org/bugzilla/show_bug.cgi?id=10339>, 
<https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5f138519ebdf88e1fc5395d65df0b780dd07829a>.  
The position of the POSIX committee WRT the API is quoted there.

 You can use autoconf to determine whether arbitrary baud rates are 
supported, by checking if one of the Bxxx macros expands to its numeric 
baud rate equivalent (you can check a couple if you feel pedantic).  

 With older versions of glibc and possibly other C library 
implementations Bxxx macros have to be used of course and the choice of 
baud rates available this way is limited.  Resorting to using the BOTHER 
flag might be the best approach, but the POSIX interface seems like the 
best first choice.

  Maciej

Re: [PATCH] gdb/ser-unix: avoid musl build failure when setting custom baud rates

[Dora, Sunil Kumar]

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

Hi Kevin, hi Maciej,

Thank you both for the feedback.

Kevin — I agree that using _HAVE_STRUCT_TERMIOS_* macros is not appropriate, since those are glibc-internal
definitions and not part of a public interface.
I will drop that approach and replace it with proper configure-time feature detection.

Maciej — Thank you for the suggestion regarding detection of arbitrary baud rate support.
Checking whether the Bxxx macros expand to their numeric baud rate equivalents is a very
clean way to determine whether cfsetospeed/cfsetispeed accept arbitrary speeds.
I will try this approach in configure to detect support.

I’ll rework the patch accordingly to:

 - Use autoconf to detect arbitrary-speed support for cfset*
 - Prefer the POSIX interface when available
 - Fall back to the termios2 (BOTHER) interface when necessary
 - Avoid relying on libc-internal definitions

I will send a v2 shortly. Thanks again for the review.

Best regards,
Sunil
________________________________
From: Maciej W. Rozycki <macro@orcam.me.uk>
Sent: Saturday, February 14, 2026 12:28 AM
To: Kevin Buettner <kevinb@redhat.com>
Cc: Dora, Sunil Kumar <SunilKumar.Dora@windriver.com>; gdb-patches@sourceware.org <gdb-patches@sourceware.org>; simon.marchi@efficios.com <simon.marchi@efficios.com>; tromey@sourceware.org <tromey@sourceware.org>; Kokkonda, Sundeep <Sundeep.Kokkonda@windriver.com>
Subject: Re: [PATCH] gdb/ser-unix: avoid musl build failure when setting custom baud rates

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Fri, 13 Feb 2026, Kevin Buettner wrote:

> 2) I don't think that it's correct to call cfsetospeed and cfsetispeed
>    with arbitrary baud rates.  According to the man page, these
>    functions expect to be passed one of the "B" constants like B1200,
>    B9600, etc, not arbitrary speeds.  The existing code which uses the
>    BOTHER extension is the correct way to do this.

 FYI as from v2.42 glibc finally does support arbitrary baud rates with
`cfsetospeed' and `cfsetispeed' with Linux as well, in addition to Hurd,
which it has been since forever.  This is fully documented in the glibc
manual; the man page you refer to is likely outdated.

 The BOTHER flag is the raw OS kernel interface and its direct use is
discouraged.

 Cf.
<https://inbox.sourceware.org/libc-alpha/20250612013546.1524096-1-hpa@zytor.com/>,
<https://sourceware.org/bugzilla/show_bug.cgi?id=10339>,
<https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5f138519ebdf88e1fc5395d65df0b780dd07829a>.
The position of the POSIX committee WRT the API is quoted there.

 You can use autoconf to determine whether arbitrary baud rates are
supported, by checking if one of the Bxxx macros expands to its numeric
baud rate equivalent (you can check a couple if you feel pedantic).

 With older versions of glibc and possibly other C library
implementations Bxxx macros have to be used of course and the choice of
baud rates available this way is limited.  Resorting to using the BOTHER
flag might be the best approach, but the POSIX interface seems like the
best first choice.

  Maciej

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