Re: [PATCH V4] PR gdb/33747: gdb/ser-unix: modernize and fix custom baud rate support on musl

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

On 3/23/2026 6:36 PM, Eli Zaretskii 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.
>
>> From: sunilkumar.dora@windriver.com
>> Cc: kevinb@redhat.com, macro@orcam.me.uk, Randy.MacLeod@windriver.com,
>>   Sundeep.Kokkonda@windriver.com, schwab@linux-m68k.org,
>>   tromey@sourceware.org, simark@simark.ca, SunilKumar.Dora@windriver.com
>> Date: Mon, 23 Mar 2026 04:27:46 -0700
>>
>> From: Sunil Dora <sunilkumar.dora@windriver.com>
>>
>> On musl-based systems, <asm/termbits.h> may expose BOTHER even though
>> struct termios does not define c_ispeed/c_ospeed.  This causes the
>> Linux-specific custom baud rate path to be compiled and fail to build.
>>
>> Fix this at the macro level by requiring HAVE_STRUCT_TERMIOS_C_OSPEED
>> alongside BOTHER in the HAVE_CUSTOM_BAUDRATE_SUPPORT guard.  This
>> prevents the Linux-specific path from being compiled on systems where
>> the required fields are unavailable, leaving set_custom_baudrate_linux()
>> unchanged.
>>
>> Introduce a platform-agnostic implementation using the POSIX
>> cfsetispeed/cfsetospeed interface, guarded by HAVE_CFSETSPEED_ARBITRARY.
>> This interface is supported by glibc 2.42 and later and is expected to
>> be standardized by a future POSIX revision.  It also covers systems
>> such as GNU Hurd that do not provide BOTHER.  Return values from
>> cfsetispeed() and cfsetospeed() are checked, and errors are reported
>> via perror_with_name().
>>
>> Update the dispatcher to prefer the POSIX implementation when available,
>> falling back to Linux-specific (BOTHER) or Darwin-specific (IOSSIOSPEED)
>> mechanisms otherwise.
>>
>> Suggested-by: Kevin Buettner <kevinb@redhat.com>
>> Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk>
>> Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
>> ---
>> Changes since V3:
>>
>>    - Moved the fix to the macro level, requiring
>>      HAVE_STRUCT_TERMIOS_C_OSPEED alongside BOTHER.
>>    - Left set_custom_baudrate_linux() completely unchanged.
>>    - Introduced set_custom_baudrate_posix(), guarded by
>>      HAVE_CFSETSPEED_ARBITRARY.
>>    - Added return value checks for cfsetispeed() and cfsetospeed().
>>    - Extended HAVE_CUSTOM_BAUDRATE_SUPPORT for systems with
>>      HAVE_CFSETSPEED_ARBITRARY.
>>    - Removed the #else error() fallback.
>>    - Updated comments to reflect the new behaviour.
>>
>>   gdb/NEWS         |  7 +++++++
>>   gdb/config.in    |  6 ++++++
>>   gdb/configure    | 52 ++++++++++++++++++++++++++++++++++++++++++++++++
>>   gdb/configure.ac | 22 ++++++++++++++++++++
>>   gdb/ser-unix.c   | 43 ++++++++++++++++++++++++++++++++++-----
>>   5 files changed, 125 insertions(+), 5 deletions(-)
> Thanks.
>
>> diff --git a/gdb/NEWS b/gdb/NEWS
>> index e46a5108272..967787783e2 100644
>> --- a/gdb/NEWS
>> +++ b/gdb/NEWS
>> @@ -36,6 +36,13 @@
>>     subsequent runs of the inferior will use the same arguments as the
>>     first run.
>>
>> +* GDB now supports arbitrary baud rates on systems where the host libc
>> +  accepts them via cfsetispeed/cfsetospeed (such as glibc 2.42+).
>> +  On Linux systems where this is not available, GDB falls back to the
>> +  termios2 (BOTHER) interface.  The legacy termios fallback is now
>> +  only compiled on systems where struct termios exposes c_ispeed
>> +  and c_ospeed.
>> +
>>   * Support for stabs debug information has been removed.
> This entry could be more useful if it explained which GDB
> functionalities are affected by these changes.  Otherwise, I'm not
> sure it will be clear to the reader whether and when should he/she be
> bothered or excited by these changes.
>
> Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Hi Eli,

Thanks for the review.
You're right — the NEWS entry was too focused on implementation details.

For V5 I simplified it to this:

* GDB now supports arbitrary (non-standard) baud rates for serial
   connections to remote targets.

Please let me know if this looks good or if you'd like any small change.

Thanks again,
Sunil