On 3/27/2026 11:45 PM, 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.

On Tue, 24 Mar 2026 09:45:25 -0700
sunilkumar.dora@windriver.com wrote:

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

On musl-based systems <asm/termbits.h> exposes BOTHER, so the
Linux-specific custom baud rate path was being compiled.  However,
musl's struct termios does not provide the public members c_ispeed
and c_ospeed, causing a build failure.

This series fixes the build issue at the macro level (patch 1).
It then adds the preferred POSIX cfsetispeed/cfsetospeed path as the
first choice on platforms where the host libc supports arbitrary baud
rates, such as glibc 2.42 and later, GNU Hurd, and potentially other
libc implementations (patch 2).  The existing Linux (termios2/BOTHER)
and Darwin (IOSSIOSPEED) paths remain as fallbacks.

The two patches are independent:
  - Patch 1 is a pure build fix with no functional change.
  - Patch 2 adds the new POSIX feature on top of the fixed guard.

set_custom_baudrate_linux is left unchanged.

Changes since V4:
  - Split into two patches, with patch 1 as a pure build fix
    and patch 2 adding the POSIX interface.
  - Fixed #if guard formatting and added full stop to the
    AC_DEFINE description.
  - Removed parentheses from function name references in
    commit messages and comments.
  - Updated NEWS entry to describe which configurations are
    affected.

v4: https://sourceware.org/pipermail/gdb-patches/2026-March/226133.html
v3: https://sourceware.org/pipermail/gdb-patches/2026-March/225952.html
v2: https://sourceware.org/pipermail/gdb-patches/2026-February/225251.html
v1: https://sourceware.org/pipermail/gdb-patches/2026-February/224968.html

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33747
Both parts are approved.  Thanks for persevering through the many
requests for changes.

One thing I noticed - Some error messages in ser-unix.c still use
"Can not" whereas you uniformly (and correctly IMO) use "Cannot".
If you're up for doing a follow-on patch, one which does
s/Can not/Cannot/ on the remaining occurrences would be appreciated.

Approved-by: Kevin Buettner <kevinb@redhat.com>

Hi Kevin,

I just wanted to check in since I don't have commit access. When you have a moment, could you please push the two patches?

Also, I'm happy to send a follow-on patch to address the remaining "Can not" -> "Cannot" occurrences in ser-unix.c.

Thanks,
Sunil Dora