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

[Kevin Buettner <kevinb@redhat.com>]

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