[PATCH v2] PR gdb/33747: gdb/ser-unix: Avoid musl build failure when setting custom baud rates

[PATCH v2] PR gdb/33747: gdb/ser-unix: Avoid musl build failure when setting custom baud rates

[sunilkumar.dora]

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

The Linux custom baud rate implementation accessed the struct termios 
members c_ispeed and c_ospeed directly. These fields are provided by 
glibc but are not exposed by musl, which causes the build to fail on 
musl-based systems.

Adjust set_custom_baudrate_linux to use a capability-based approach.
The Autoconf check HAVE_NUMERIC_BAUD_RATES determines whether
B-constants match numeric baud rates. If they do, use the standard
POSIX cfsetispeed and cfsetospeed interfaces. Otherwise, fall back
to the Linux-specific termios2 interface (TCGETS2) to support
arbitrary baud rates.

This preserves existing behavior on glibc systems while restoring
build compatibility with musl.

Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
---
 gdb/NEWS         |  4 ++++
 gdb/config.in    |  3 +++
 gdb/configure    | 39 +++++++++++++++++++++++++++++++++++++++
 gdb/configure.ac | 19 +++++++++++++++++++
 gdb/ser-unix.c   | 42 ++++++++++++++++++++++++++----------------
 5 files changed, 91 insertions(+), 16 deletions(-)

diff --git a/gdb/NEWS b/gdb/NEWS
index 47d8189d344..003a1700492 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -36,6 +36,10 @@
   subsequent runs of the inferior will use the same arguments as the
   first run.
 
+* GDB now detects if the host system uses numeric values for termios
+  B-constants.  If not, GDB now uses the Linux termios2 interface to
+  support custom baud rates.
+
 * Support for stabs debug information has been removed.
 
 * Support for mdebug debug information has been removed.
diff --git a/gdb/config.in b/gdb/config.in
index b11fcf18372..a7b8ca16d8c 100644
--- a/gdb/config.in
+++ b/gdb/config.in
@@ -346,6 +346,9 @@
 /* Define to 1 if you have the <nlist.h> header file. */
 #undef HAVE_NLIST_H
 
+/* Define if termios B-constants match their numeric baud rate */
+#undef HAVE_NUMERIC_BAUD_RATES
+
 /* Define to 1 if you have the `pipe' function. */
 #undef HAVE_PIPE
 
diff --git a/gdb/configure b/gdb/configure
index 12c54521682..aee49cc7d74 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -27728,6 +27728,45 @@ if test "$ac_res" != no; then :
 fi
 
 
+# Check whether termios B-constants match their numeric baud rate.
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether termios B-constants are numeric" >&5
+$as_echo_n "checking whether termios B-constants are numeric... " >&6; }
+if ${gdb_cv_termios_numeric_baud+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include <termios.h>
+int
+main ()
+{
+
+       #if B9600 != 9600
+       #error B-constants are not numeric symbols
+       #endif
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  gdb_cv_termios_numeric_baud=yes
+else
+  gdb_cv_termios_numeric_baud=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gdb_cv_termios_numeric_baud" >&5
+$as_echo "$gdb_cv_termios_numeric_baud" >&6; }
+
+if test "$gdb_cv_termios_numeric_baud" = yes; then
+
+$as_echo "#define HAVE_NUMERIC_BAUD_RATES 1" >>confdefs.h
+
+fi
+
 
 
 # Check whether --with-jit-reader-dir was given.
diff --git a/gdb/configure.ac b/gdb/configure.ac
index cf8078e1d89..ef8f085c824 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -725,6 +725,25 @@ AC_CONFIG_FILES([jit-reader.h:jit-reader.in])
 
 AC_SEARCH_LIBS(dlopen, dl)
 
+# Check whether termios B-constants match their numeric baud rate.
+AC_CACHE_CHECK([whether termios B-constants are numeric],
+  [gdb_cv_termios_numeric_baud], [
+  AC_COMPILE_IFELSE(
+    [AC_LANG_PROGRAM([[#include <termios.h>]],
+      [[
+       #if B9600 != 9600
+       #error B-constants are not numeric symbols
+       #endif
+      ]])],
+    [gdb_cv_termios_numeric_baud=yes],
+    [gdb_cv_termios_numeric_baud=no])
+])
+
+if test "$gdb_cv_termios_numeric_baud" = yes; then
+  AC_DEFINE([HAVE_NUMERIC_BAUD_RATES], [1],
+	    [Define if termios B-constants match their numeric baud rate])
+fi
+
 GDB_AC_WITH_DIR([JIT_READER_DIR], [jit-reader-dir],
 		[directory to load the JIT readers from],
 		[${libdir}/gdb])
diff --git a/gdb/ser-unix.c b/gdb/ser-unix.c
index c295a9c5ba1..410639ca460 100644
--- a/gdb/ser-unix.c
+++ b/gdb/ser-unix.c
@@ -515,31 +515,41 @@ 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
+#if defined (HAVE_NUMERIC_BAUD_RATES)
   struct termios tio;
-  const unsigned long req_get = TCGETS;
-  const unsigned long req_set = TCSETS;
-#endif
 
-  if (ioctl (fd, req_get, &tio) < 0)
+  if (tcgetattr (fd, &tio) < 0)
+    perror_with_name (_("Can not get current baud rate"));
+
+  cfsetispeed (&tio, rate);
+  cfsetospeed (&tio, rate);
+
+  if (tcsetattr (fd, TCSANOW, &tio) < 0)
+    perror_with_name (_("Can not set custom baud rate"));
+
+#elif defined (TCGETS2)
+  /* Use the kernel-level termios2 structure.  */
+  struct termios2 tio2;
+
+  if (ioctl (fd, TCGETS2, &tio2) < 0)
     perror_with_name (_("Can not get current baud 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;
+  tio2.c_cflag |= BOTHER;
+  tio2.c_ospeed = 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;
+  tio2.c_cflag &= ~(CBAUD << IBSHIFT);
+  tio2.c_cflag |= BOTHER << IBSHIFT;
+  tio2.c_ispeed = rate;
 
-  if (ioctl (fd, req_set, &tio) < 0)
+  if (ioctl (fd, TCSETS2, &tio2) < 0)
     perror_with_name (_("Can not set custom baud rate"));
+
+#else
+  perror_with_name (_("Custom baud rate not supported on this platform"));
+#endif
 }
 
 #elif HAVE_CUSTOM_BAUDRATE_SUPPORT && defined(IOSSIOSPEED)
-- 
2.49.0

Re: [PATCH v2] PR gdb/33747: gdb/ser-unix: Avoid musl build failure when setting custom baud rates

[Eli Zaretskii]

> From: sunilkumar.dora@windriver.com
> Cc: sunilkumar.dora@windriver.com, Randy.MacLeod@windriver.com,
>  Sundeep.Kokkonda@windriver.com, kevinb@redhat.com, macro@orcam.me.uk,
>  schwab@linux-m68k.org, tromey@sourceware.org, simark@simark.ca
> Date: Sun, 22 Feb 2026 12:06:48 -0800
> 
> From: Sunil Dora <sunilkumar.dora@windriver.com>
> 
> The Linux custom baud rate implementation accessed the struct termios 
> members c_ispeed and c_ospeed directly. These fields are provided by 
> glibc but are not exposed by musl, which causes the build to fail on 
> musl-based systems.
> 
> Adjust set_custom_baudrate_linux to use a capability-based approach.
> The Autoconf check HAVE_NUMERIC_BAUD_RATES determines whether
> B-constants match numeric baud rates. If they do, use the standard
> POSIX cfsetispeed and cfsetospeed interfaces. Otherwise, fall back
> to the Linux-specific termios2 interface (TCGETS2) to support
> arbitrary baud rates.
> 
> This preserves existing behavior on glibc systems while restoring
> build compatibility with musl.
> 
> Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
> ---
>  gdb/NEWS         |  4 ++++
>  gdb/config.in    |  3 +++
>  gdb/configure    | 39 +++++++++++++++++++++++++++++++++++++++
>  gdb/configure.ac | 19 +++++++++++++++++++
>  gdb/ser-unix.c   | 42 ++++++++++++++++++++++++++----------------
>  5 files changed, 91 insertions(+), 16 deletions(-)

Thanks, the NEWS part is approved.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Re: [PATCH v2] PR gdb/33747: gdb/ser-unix: Avoid musl build failure when setting custom baud rates

[Kevin Buettner]

Hi Sunil,

On Sun, 22 Feb 2026 12:06:48 -0800
sunilkumar.dora@windriver.com wrote:

> From: Sunil Dora <sunilkumar.dora@windriver.com>
> 
> The Linux custom baud rate implementation accessed the struct termios 
> members c_ispeed and c_ospeed directly. These fields are provided by 
> glibc but are not exposed by musl, which causes the build to fail on 
> musl-based systems.
> 
> Adjust set_custom_baudrate_linux to use a capability-based approach.
> The Autoconf check HAVE_NUMERIC_BAUD_RATES determines whether
> B-constants match numeric baud rates. If they do, use the standard
> POSIX cfsetispeed and cfsetospeed interfaces. Otherwise, fall back
> to the Linux-specific termios2 interface (TCGETS2) to support
> arbitrary baud rates.
> 
> This preserves existing behavior on glibc systems while restoring
> build compatibility with musl.

Here are my concerns:

1) The name HAVE_NUMERIC_BAUD_RATES doesn't really describe the
   feature that we wish to test for.  I think it should convey
   the fact that the implementations of cfsetospeed/cfsetispeed
   available on the platform are capable of accepting (and correctly
   using) arbitrary baud rate values.  Potential names include
   HAVE_CFSETSPEED_ARBITRARY and HAVE_ARBITRARY_BAUD_CFSETSPEED.
   (But if you have some other sensible preference, that's fine
   too.)

2) I don't think that the final perror_with_name() call is correct. 
   (I.e.  the one after the #else.) perror_with_name() should be used
   to print out an error message after calling a function associated
   with some underlying syscall.  But in this instance, there is no
   call - I think you ought to just be using a call to error().

3) I'd like to better understand what we might be losing by
   eliminating the fallback to TCGETS.

4) You might change the commit title to something along the lines
   of "Modernize custom baudrate handling" or some such. This patch
   does much more than narrowly fixing the MUSL build failure.

Kevin

Re: [PATCH v2] PR gdb/33747: gdb/ser-unix: Avoid musl build failure when setting custom baud rates

[Sunil Kumar Dora]

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

Hi Kevin,

On 3/9/2026 6:55 AM, Kevin Buettner wrote:
> 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.
>
> Hi Sunil,
>
> On Sun, 22 Feb 2026 12:06:48 -0800
> sunilkumar.dora@windriver.com wrote:
>
>> From: Sunil Dora<sunilkumar.dora@windriver.com>
>>
>> The Linux custom baud rate implementation accessed the struct termios
>> members c_ispeed and c_ospeed directly. These fields are provided by
>> glibc but are not exposed by musl, which causes the build to fail on
>> musl-based systems.
>>
>> Adjust set_custom_baudrate_linux to use a capability-based approach.
>> The Autoconf check HAVE_NUMERIC_BAUD_RATES determines whether
>> B-constants match numeric baud rates. If they do, use the standard
>> POSIX cfsetispeed and cfsetospeed interfaces. Otherwise, fall back
>> to the Linux-specific termios2 interface (TCGETS2) to support
>> arbitrary baud rates.
>>
>> This preserves existing behavior on glibc systems while restoring
>> build compatibility with musl.
> Here are my concerns:
>
> 1) The name HAVE_NUMERIC_BAUD_RATES doesn't really describe the
>     feature that we wish to test for.  I think it should convey
>     the fact that the implementations of cfsetospeed/cfsetispeed
>     available on the platform are capable of accepting (and correctly
>     using) arbitrary baud rate values.  Potential names include
>     HAVE_CFSETSPEED_ARBITRARY and HAVE_ARBITRARY_BAUD_CFSETSPEED.
>     (But if you have some other sensible preference, that's fine
>     too.)
Thanks for pointing that out. I will rename the Autoconf check to 
HAVE_CFSETSPEED_ARBITRARY
in the next version.
>
> 2) I don't think that the final perror_with_name() call is correct.
>     (I.e.  the one after the #else.) perror_with_name() should be used
>     to print out an error message after calling a function associated
>     with some underlying syscall.  But in this instance, there is no
>     call - I think you ought to just be using a call to error().
You're right. I will replace perror_with_name() with a regular error() 
call.
>
> 3) I'd like to better understand what we might be losing by
>     eliminating the fallback to TCGETS.
While looking into this, I noticed that on some architectures such as 
PowerPC and Alpha, the normal
/struct termios/ (not /termios2/) actually has /c_ispeed/ and /c_ospeed/ 
fields. Because of this,
those systems *might *still support custom baud rates using the older 
/TCGETS/ interface.

The *build failure on musl *happens because musl follows strict POSIX, 
and its /struct termios/ does not
include these members (`/c_ispeed`/ and `/c_ospeed`/) on any architecture.

To handle both cases, would it make sense to keep the /TCGETS/ fallback 
but guard it with a feature check like
/AC_CHECK_MEMBERS([struct termios.c_ospeed])/?

That way we can still support the legacy behavior on glibc systems, 
while avoiding build issues on musl
where those fields don't exist.

This would result in something like the following compile-time paths:
----
/#if defined(HAVE_CFSETSPEED_ARBITRARY)
   /* Use cfsetispeed()/cfsetospeed() */

#elif defined(TCGETS2)
   /* Use Linux termios2 interface with BOTHER */

#elif defined(HAVE_STRUCT_TERMIOS_C_OSPEED) && defined(BOTHER)
   /* Legacy fallback using TCGETS/TCSETS */

#else
   /* Custom baud rates not supported */
#endif/


I’m thinking this might be a reasonable approach, but please let me know 
if I’m missing something.

>
> 4) You might change the commit title to something along the lines
>     of "Modernize custom baudrate handling" or some such. This patch
>     does much more than narrowly fixing the MUSL build failure.
Yes, that makes sense. I will update the commit title in the next version.
>
> Kevin
>

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

Re: [PATCH v2] PR gdb/33747: gdb/ser-unix: Avoid musl build failure when setting custom baud rates

[Kevin Buettner]

On Tue, 10 Mar 2026 19:08:15 +0530
Sunil Kumar Dora <sunilkumar.dora@windriver.com> wrote:

> > 3) I'd like to better understand what we might be losing by
> >     eliminating the fallback to TCGETS.  
> While looking into this, I noticed that on some architectures such as 
> PowerPC and Alpha, the normal
> /struct termios/ (not /termios2/) actually has /c_ispeed/ and /c_ospeed/ 
> fields. Because of this,
> those systems *might *still support custom baud rates using the older 
> /TCGETS/ interface.
> 
> The *build failure on musl *happens because musl follows strict POSIX, 
> and its /struct termios/ does not
> include these members (`/c_ispeed`/ and `/c_ospeed`/) on any architecture.
> 
> To handle both cases, would it make sense to keep the /TCGETS/ fallback 
> but guard it with a feature check like
> /AC_CHECK_MEMBERS([struct termios.c_ospeed])/?
> 
> That way we can still support the legacy behavior on glibc systems, 
> while avoiding build issues on musl
> where those fields don't exist.
> 
> This would result in something like the following compile-time paths:
> ----
> /#if defined(HAVE_CFSETSPEED_ARBITRARY)
>    /* Use cfsetispeed()/cfsetospeed() */
> 
> #elif defined(TCGETS2)
>    /* Use Linux termios2 interface with BOTHER */
> 
> #elif defined(HAVE_STRUCT_TERMIOS_C_OSPEED) && defined(BOTHER)
>    /* Legacy fallback using TCGETS/TCSETS */
> 
> #else
>    /* Custom baud rates not supported */
> #endif/
> 
> 
> I’m thinking this might be a reasonable approach, but please let me know 
> if I’m missing something.

That approach looks reasonable to me.

Kevin