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

[Sunil Kumar Dora <sunilkumar.dora@windriver.com>]

[-- 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 --]