From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uU2VD6Ahrmlw0h0AWB0awg (envelope-from ) for ; Sun, 08 Mar 2026 21:25:52 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=XC+3bR7E; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 368601E0DD; Sun, 08 Mar 2026 21:25:52 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 989EB1E089 for ; Sun, 08 Mar 2026 21:25:51 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 39A784BA23F4 for ; Mon, 9 Mar 2026 01:25:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 39A784BA23F4 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=XC+3bR7E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 146D14BA2E1C for ; Mon, 9 Mar 2026 01:25:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 146D14BA2E1C Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 146D14BA2E1C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773019524; cv=none; b=J6XYX6RjTUWIboNUWdwvE78kQpbs0sPeXwRbpUJm/zmb2yPFRaF6m+ID9fmmbhKuwBeW7sehAcwG2eDHenuFS/M9W3zbnKsF7uG3T7fYS1KMoP/+HDuGMt+8/jy4vl8q/zsItzw/DsnSONyL3wPybSp1LfWGMocu2GXh+wfLI/E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773019524; c=relaxed/simple; bh=9MXGRn1in7njpH+/VPqiTvus7kx6I0MUQr7/P88SgFU=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=E89ahaXtNU/8rOIeuoennOGIzF1JiQXTv8i+9l0eZ8eCiPeyTQNICvuEPt6zFca+rI+nV2b77Qrf14pSZtAYuqZprB7w2/5HTsCNOq/XdR9pCpt8gKqvOFVKPmgK86kxVTy9w47WUCEQUSzEIOMYcLAG4EjNvI+Hlu2GYHPQnvo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 146D14BA2E1C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773019523; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VRiVwT6Ocs+4iIHoZ7FUItXMXVase0M5vqvMM9narcQ=; b=XC+3bR7E1R/Ha8K1jV/W9rnPCT6DoYJOO7PK6fqFljQj+1H+T2FVDzINilTG0H48uedve0 1KzAX3/5TomNJ/GDHG7mdf1+3yumL87KjUImd/GSNgkiV9AFlfK6CrZlaIorsR/Sd9+qF4 nPs/jqxBOVjoi07lNyyb0w80VXir8/A= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-576-1dKk4V7kPQaEn_cIPonM6Q-1; Sun, 08 Mar 2026 21:25:17 -0400 X-MC-Unique: 1dKk4V7kPQaEn_cIPonM6Q-1 X-Mimecast-MFC-AGG-ID: 1dKk4V7kPQaEn_cIPonM6Q_1773019515 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 852CA1956050; Mon, 9 Mar 2026 01:25:14 +0000 (UTC) Received: from f42-zbm-amd (unknown [10.22.88.47]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C8FA71956095; Mon, 9 Mar 2026 01:25:11 +0000 (UTC) Date: Sun, 8 Mar 2026 18:25:09 -0700 From: Kevin Buettner To: sunilkumar.dora@windriver.com Cc: gdb-patches@sourceware.org, Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, macro@orcam.me.uk, schwab@linux-m68k.org, tromey@sourceware.org, simark@simark.ca Subject: Re: [PATCH v2] PR gdb/33747: gdb/ser-unix: Avoid musl build failure when setting custom baud rates Message-ID: <20260308182509.18b4fe0d@f42-zbm-amd> In-Reply-To: <20260222200648.2648865-1-sunilkumar.dora@windriver.com> References: <20260222200648.2648865-1-sunilkumar.dora@windriver.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: PDO5q2qiTcPw4x0qI2Ot7zrVJbqyVg8WTRdA4aOQrms_1773019515 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Sunil, On Sun, 22 Feb 2026 12:06:48 -0800 sunilkumar.dora@windriver.com wrote: > From: Sunil Dora > > 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