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

[Kevin Buettner <kevinb@redhat.com>]

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