From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id brh4FLZoj2knjzkAWB0awg (envelope-from ) for ; Fri, 13 Feb 2026 13:08:54 -0500 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=BovGmAnG; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 37E351E08D; Fri, 13 Feb 2026 13:08:54 -0500 (EST) 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 4EFFC1E08D for ; Fri, 13 Feb 2026 13:08:53 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 5C59B4B9DB66 for ; Fri, 13 Feb 2026 18:08:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C59B4B9DB66 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=BovGmAnG Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 4E4674BA23FE for ; Fri, 13 Feb 2026 18:08:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E4674BA23FE 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 4E4674BA23FE Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771006105; cv=none; b=FDqo0UW+HvwMY1WOLaRX12rvys0RqYkS6e4C2Wz0SQzCkHk5NEv2xsPLMptVwaFo/Zr6NulNon/SPWnZnRFE34C7ivSxk2GhI/I2e3EfJdoRCoTs/Ia4i07MilVspls0EVFyam+k/LbPDIzzqyi6Bd1yTUpYEcjEevwjI9zmuno= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771006105; c=relaxed/simple; bh=LUeJkkvGIvFo4Fs4hSb57RSUwFDq52sq0xkJohtGwR4=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=uF8CJusNlHyGGaotB5W/buH0mu9XkhLe1uPJyAWWYdlDBbrTVLEONvblIXUQGncZgPKVUib2gu8Am0vv0mPn57wM4NNLxZ/J18K9+V4E8SzvlTeXFo2yyk81faZoT+ZW+Q1FRcYx3rnkwt8RnsT8eaYU/JR9FM5MAwtoOdtVaVc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4E4674BA23FE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771006105; 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=4oSz+MT9vm+NMzmh1OAR2dcE7tdgZCIGvkZK8F3EDNo=; b=BovGmAnG7q3tiR1Tx8SvVU49ynwwyJbFOImuW3Accj0noB8ECrm7JJWCKBR9/GkuDH/AMu pTQwNEPfN8ZdHOwra8cDUUdWWYtbBJ5L+g7EUYtyoyg4UJ9g0h9LP2jiInihvtL/3J7vjt PJhMD0HsbplVICzAtD+RvLnw93zV2Ck= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-481-rpuwAwSCN8CrfL2n73HBcA-1; Fri, 13 Feb 2026 13:08:23 -0500 X-MC-Unique: rpuwAwSCN8CrfL2n73HBcA-1 X-Mimecast-MFC-AGG-ID: rpuwAwSCN8CrfL2n73HBcA_1771006102 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0951E1800259; Fri, 13 Feb 2026 18:08:22 +0000 (UTC) Received: from f42-zbm-amd (unknown [10.22.88.16]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D6B9E19560B9; Fri, 13 Feb 2026 18:08:19 +0000 (UTC) Date: Fri, 13 Feb 2026 11:08:17 -0700 From: Kevin Buettner To: sunilkumar.dora@windriver.com Cc: gdb-patches@sourceware.org, simon.marchi@efficios.com, tromey@sourceware.org, Sundeep.Kokkonda@windriver.com Subject: Re: [PATCH] gdb/ser-unix: avoid musl build failure when setting custom baud rates Message-ID: <20260213110817.10346c83@f42-zbm-amd> In-Reply-To: <20260213152151.3224544-1-sunilkumar.dora@windriver.com> References: <20260213152151.3224544-1-sunilkumar.dora@windriver.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: DPOxje9eC3jwS1LH-3LcLDfQwd3KAwkHLX-jtdJM2uA_1771006102 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 On Fri, 13 Feb 2026 07:21:51 -0800 sunilkumar.dora@windriver.com wrote: > From: Sunil Dora > > GDB's Linux custom baud rate implementation accessed the non-standard > struct termios members c_ispeed and c_ospeed directly. These members > are provided by glibc but are not exposed by musl, causing the build > to fail with errors such as: > > error: no member named 'c_ospeed' in 'termios' > error: no member named 'c_ispeed' in 'termios' > > Musl follows strict POSIX semantics and does not expose these > implementation-specific fields. In addition, cfsetospeed/cfsetispeed > may reject non-standard baud rates, and the Linux-specific termios2 > interface is not always available through musl libc headers. > > Refactor set_custom_baudrate_linux to use a layered approach: > > 1. Attempt to use cfsetospeed/cfsetispeed > 2. Attempt to use the Linux termios2 interface (TCGETS2/TCSETS2) > when available. > 3. Fall back to direct struct termios field access only when the > required fields are exposed by the libc. > > If none of these mechanisms succeed, report an error. > > This preserves existing behavior on glibc systems while avoiding > build failures on musl-based systems. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33747 > > * gdb/ser-unix.c (set_custom_baudrate_linux): Refactor custom > baud rate handling to avoid unconditional use of non-standard > termios members. > > Signed-off-by: Sunil Dora > --- > gdb/ser-unix.c | 68 ++++++++++++++++++++++++++++++++++++-------------- > 1 file changed, 49 insertions(+), 19 deletions(-) > > diff --git a/gdb/ser-unix.c b/gdb/ser-unix.c > index c295a9c5ba1..571a59ab280 100644 > --- a/gdb/ser-unix.c > +++ b/gdb/ser-unix.c > @@ -515,31 +515,61 @@ set_baudcode_baudrate (struct serial *scb, int > baud_code) static void > set_custom_baudrate_linux (int fd, int rate) > { > -#ifdef TCGETS2 > - struct termios2 tio; > - const unsigned long req_get = TCGETS2; > - const unsigned long req_set = TCSETS2; > -#else > + /* Standard POSIX API */ > +#if defined (_HAVE_STRUCT_TERMIOS_C_OSPEED) \ > + || defined (_HAVE_STRUCT_TERMIOS_C_ISPEED) > struct termios tio; > - const unsigned long req_get = TCGETS; > - const unsigned long req_set = TCSETS; > + if (ioctl (fd, TCGETS, &tio) == 0) > + { > + if (cfsetospeed (&tio, rate) == 0 && cfsetispeed (&tio, rate) == 0) > + { > + if (ioctl (fd, TCSETS, &tio) == 0) > + return; > + } > + } > #endif I'm concerned about a couple of things in this part of your patch: 1) I don't think it's a good idea to use _HAVE_STRUCT_TERMIOS_C_OSPEED and _HAVE_STRUCT_TERMIOS_C_ISPEED within GDB. These are glibc-internal macros (defined in bits/termios-struct.h for glibc's own use in speed.c), not part of any public API. I think that the right way to do this is to use some suitable autoconf feature test to select this code. 2) I don't think that it's correct to call cfsetospeed and cfsetispeed with arbitrary baud rates. According to the man page, these functions expect to be passed one of the "B" constants like B1200, B9600, etc, not arbitrary speeds. The existing code which uses the BOTHER extension is the correct way to do this. Kevin