From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cb52ABIfsGk1ryEAWB0awg (envelope-from ) for ; Tue, 10 Mar 2026 09:39:30 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=windriver.com header.i=@windriver.com header.a=rsa-sha256 header.s=PPS06212021 header.b=lBaB3KNo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EF5D01E0DD; Tue, 10 Mar 2026 09:39:29 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,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 B54B11E08D for ; Tue, 10 Mar 2026 09:39:28 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id B73B94B9DB48 for ; Tue, 10 Mar 2026 13:39:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B73B94B9DB48 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=windriver.com header.i=@windriver.com header.a=rsa-sha256 header.s=PPS06212021 header.b=lBaB3KNo Received: from mx0a-0064b401.pphosted.com (mx0a-0064b401.pphosted.com [205.220.166.238]) by sourceware.org (Postfix) with ESMTPS id 3C5D04BA23CA; Tue, 10 Mar 2026 13:38:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3C5D04BA23CA Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=windriver.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=windriver.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3C5D04BA23CA Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=205.220.166.238 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1773149935; cv=pass; b=Fu8wk13hlH+9+QR4vQ3ctUeUzfuFZLaMGRxOGnsgJJFL46GKhzofkZTEwsUTNoWP8sUhnD6qCXhyBEzzaaw9fz2FU8u2CnE7G5vl3ayzr9oAXDPbSE1r9dwY47w0fL7h/dbEZ4BpOeaPgfcFB/RnL5LtvnvPLIqEcIIlKUEf9RU= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1773149935; c=relaxed/simple; bh=XpgveYau9Yi+xIZHFyA5YtPbJIwd8avz8YQJtkiFpd4=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=SKc6ArdJce8ED+sx02+NIu1L20u6IN2/vINM08Xgfi2jXJiAzXvI+QBfLKtkYiETs1PVHcQHjTo68II88K1wpwWL8Hiwt3gmII416miiGP6bvk8Pn8mNABxIMykbheTEqoL5CtMzFE5qne7641Y4ItyGZBHsDVUXOh8/4jVxxpE= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3C5D04BA23CA Received: from pps.filterd (m0250809.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62ACXMtU1204707; Tue, 10 Mar 2026 06:38:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=windriver.com; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=PPS06212021; bh=0GEmkExdUEFPZtaU63VOxM RCxNlQUTUpK3o9XVgTd6I=; b=lBaB3KNoc0Vs2rqjsyYWn+Py8Rx1UFqGT9Ycbd 4QV98ll+6ufMQo8OBg/NKD0IGx+NmklyvTHxyCkP864Ac7QErjDvSHVDqgylMZUG 0dG2fy6/+CvMKMgrsc1SE7s5o/wMbDzQ89oChpoSxYSNm+15H95XbVwDnVXlCKIH m23o9ILRzk4funykd74RVx4i9H9FDUqfmxABMamOXaAQBxso8GDXVlwZEAz98BvL 1HLEA1X9wtDT1sajC+lU+x/SX8O8hlXdZfvA3GTr078K8WJQ3Y1pRKQx5KU5vegK 5edsiRdY3IvhyKGyT68BJQqCSDyNt+kFw1p96FzgDvjRpW4A== Received: from bl0pr03cu003.outbound.protection.outlook.com (mail-eastusazon11012012.outbound.protection.outlook.com [52.101.53.12]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4crmdm31gs-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 10 Mar 2026 06:38:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YwgUAjZcPlOg337yNSX1bz8fmIRDVmcQaBgURGMe8sTYkWN/qVwQEMZ7vXCCjz7BsW+wk7+C2zf3bkjcrUponEQY5X0QWWJB6RN1UvdkLlAmuEzM6FUWKzb12WW+g5xbbNzWcp0mNFssxpht4GVzg8rqlGicDxYZCZcoNLKQLCxk+UHBGjrMj/+xeEyMv8XbLsiFdHjPLdciLlQsyr3950O08n+7Agsm6AeKNqIYP9lfB9KM7zkrdkWuiMZCrXlkZgcDTi79/Kvh0z33BPFto9avSCFEC7EvRmiup2aYnLekfgPwgl4Awx/w+U43GiKbmMK0+zYIqqhL9oCjh5ctvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0GEmkExdUEFPZtaU63VOxMRCxNlQUTUpK3o9XVgTd6I=; b=qGQzvhOA0OTB4k9dDvtO03H6Y75PFf/g4ZH2KLOBDRs9h0S9FJr5e0wBEn19XlVBIsEetafki9s1v8Ml+/Xr799jCop4z8cJRyXHrfKjp9S98xjQiC9sC+yM0N/r9bz9AY6pmqku+po7HE8sVbqrz10QvCnAVNOxznlV7TTFYdcsGZjaLyY03V+EmFJ4xhpNzCcTrSC9j43s3PuaccSyl18WW0IAF9W16uhgy3Ddz85xIYCLh2p4A/yeBoks12l1KPaotP/OWeqMm6vWHejMovCkQkrRxNI2bRyHWLfy1d3MaaHhVapQ786fGYg9+GScYjlpZM32PvWhAPSAEUzI2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) by PH7PR11MB7594.namprd11.prod.outlook.com (2603:10b6:510:268::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Tue, 10 Mar 2026 13:38:23 +0000 Received: from DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::4293:7c4b:a0b5:eb5f]) by DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::4293:7c4b:a0b5:eb5f%3]) with mapi id 15.20.9700.010; Tue, 10 Mar 2026 13:38:22 +0000 Content-Type: multipart/alternative; boundary="------------VDuPUEZeP2CQ8PAOYCpPD2ou" Message-ID: <5eed2d46-87fe-4a75-8246-bcda5438d826@windriver.com> Date: Tue, 10 Mar 2026 19:08:15 +0530 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] PR gdb/33747: gdb/ser-unix: Avoid musl build failure when setting custom baud rates To: Kevin Buettner 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 References: <20260222200648.2648865-1-sunilkumar.dora@windriver.com> <20260308182509.18b4fe0d@f42-zbm-amd> Content-Language: en-US From: Sunil Kumar Dora In-Reply-To: <20260308182509.18b4fe0d@f42-zbm-amd> X-ClientProxiedBy: BM1PR01CA0157.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:68::27) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|PH7PR11MB7594:EE_ X-MS-Office365-Filtering-Correlation-Id: 194673cb-5f6e-406a-ebba-08de7eaa4c41 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|376014|366016|1800799024|22082099002|8096899003; X-Microsoft-Antispam-Message-Info: BDrpMfrlWM4l4r5Giou3Oi4lWGkG2Y2B5aGRw/4x0RIqP2Q9yO/XvtwbRP7hITuC2WK/wFWcg3qpRcrHQhzHLhDvU2TeQ/P119OPHpU/UHkZtam5/yu8iYy5NWIqWxHfgoqUjSSW7CFzWGFHeLAhtZUOuuQhBupMZstwvNVbku5WjgW1uOx7gfBfFIEp4kfSRHKVJ9Q+pMQXdQvIPmMJhSaSoUyhzcS56wb4K4oN/IokLHEVdgs6HQLa9RiXN/LMDcbrW+PpCqDMZZ6qB/nN9VSmpHeAOVzX5OiXe6GGvRpA8zw1K1n3Un9hkWlmg/zTfjYxjtK0YINwi9ri6sX2MS8j+VTHkYD28rJgo6XEtMVVU+X5LH+jOaxr1f353XjT7O96bxckBDFDtwMfUbTRs1BI1ucAqqWTn5mssQGMLTtonvhlM4638SrwT3Rc6drgwdP0z0lfRCUNOlXuiIcI/rr6INib4TQ4r6JJYjiWNSaNtyaeSdiJQYFjLwo8P/GZNDxn0tGDUH/2LpPPyOZYS0lT8P0U1/AjYat7LM1mvcv+iE9qsV2q/GuZE6yWC3Ha4U293555Dg2lrXKE/OUsM1SxuS4BA9tw2gVeXUCiHPFgTu/V3gS+8OBfDYk3iHG46BLto/xU71J25ZlmiPbETNjeFWBkKRPAOAPwoTo0hseYWrwnoX2Fjz6Bt8U3Ww1oD3JQu3BUWK0SMIVMhpIlvnrxtpD2yIu341kh7O9ORno= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7901.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(366016)(1800799024)(22082099002)(8096899003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UlozWEFlMDNocDMwOTFleUszb2ljK05kTVFWL3VleWp6YWhpSSt1U1ZhNVIz?= =?utf-8?B?UGxkbUx1UFkwUzNlQ2tpTDBqUXhWSS9sNVl0L2NycDAzV0dLcW5nV0E0NC83?= =?utf-8?B?dVlZbDBQcGpIcHdvMU1rbmkzY3ZZMllaaTV5clpWWEY4WXlnV1RqcGdCS240?= =?utf-8?B?Sk5MRUFlYjl0bTI5cFRqOTJnM1R6dVp5bXF3TE1wdkhweFVGQjFJZUdIQnB2?= =?utf-8?B?R0dTaHFETzgwTThWZmQramdneXVMVkxGUm1qbVJXK1pPN3hRTFA3RmZmdEx6?= =?utf-8?B?MFFhSjByRnJCYTQ1dHBZYnZoc2VLVW82WG5aYWdxOXFTZnl3cExGd2UwQWEz?= =?utf-8?B?dU5OZy9RbU1uVWt0WWp1TzhKUmh1MVFaNUptNUFBcitOSWNlVDVrQnByVkts?= =?utf-8?B?U3QrKytHc0ZKZ1lUdUIwUmdXVWZzQ2Ruekw4bDNlMkRhZTBoWnB6dlZzQXNm?= =?utf-8?B?TWUyM2VQZEF6NEs0WlZ2ejBnZXRkd1FmcktOR09zQnZkU0EvK0ptM1pSNnQ0?= =?utf-8?B?T3FJdUpaT1NiZzliWjNBQ1VHU2tSUE5LNlpTT3luQnZINjNUbXVvL0VEV2py?= =?utf-8?B?Q1lPdVZ1WmIwSzYrZDd4c0hHMEc3bWpQcXVWMjBqVkh0MG1uUGowb2w2VEcw?= =?utf-8?B?U3l1K2VDd3dmL010NVNmZ3pkSFF5MTJTaDJ6Ly9Yd2paOFJhdmhGeWUxbDI1?= =?utf-8?B?RXVzQ0VpU25RcFF5YUI4cTVmc1Z2eUdHZzUxV3p3VUJyZWtHcTRVbDhJM1JL?= =?utf-8?B?S3E5Q0ZweTcwdFBGdmxzcHdma2lFMktrcmFVaUhKRU5XWkdYdVJ6V2wzVlJa?= =?utf-8?B?TElrdWorR1hRTkErNEdHdEJHVDlXSWNqV1NsV09jd1R1Y2JlZktNNU55cDEx?= =?utf-8?B?a1ZRR2JpZTNDSHJHZUJjWFhJeUE0MEpKTGM4RzhVdGU2UlRJUWJuc2trUUhX?= =?utf-8?B?dmo5YlMzaHNrdXQ5UUhCQWxqN25GeUJRc0E3Y3JCT3JSaEh5eXB1Y2dtSFNC?= =?utf-8?B?UWVpUlp4SEQ4Q3pNSzFPNGVZazJaekNwY0ZSSFp2Sm5DbjVBTExmM3B1aU1N?= =?utf-8?B?cjhRS2Rvdy9heTZ5QmRHenNxYkErNlhHWlI1aDNvMmlyVmNEUEFpMnBaeG9q?= =?utf-8?B?YmkyaXFLQjB0dXVuL3VrV05QOUthS0MxZGtyQ2tra3VKeDNpUHdZVDhRSG9t?= =?utf-8?B?NHRyQWFsamx1K0FlUmx5ZjBaQ0piNHZDeXAyYmtmVFQzMWxtL0xSN0VIU25i?= =?utf-8?B?bzdwK2tkUUhwY0JwS1JSbTNqa2pIM1B6VXRRejI1STJUMTdKUjlySXJteXJr?= =?utf-8?B?cm1wN1p1VEo2MUNteG0xU3lUMHIxNSszWkw2RjVnQUdUbVhzQkpCbnZJU2FE?= =?utf-8?B?OW1QNFNMMDlDK3UvNVVIR0s2bnRWRXg5NzhzSUkrbXNRcXVSZUlIZnJPcjI2?= =?utf-8?B?OVROc3Z2ZHI0L2JZUHIvL1l0cmo1VThqc1ZaSCtZMkhMU24vVFNlV2pkSjJp?= =?utf-8?B?ajdFaDVxakI4KzR2OHpWc2dTWkdHOHI1RGVqNi9ZUm1ldWdadzR2OFNOUXBl?= =?utf-8?B?M0FyTHZvSEVESFl2RHJJSm55b3VqZ0FkTFc3L1grNE1KVDU0Qk1sL0s3RUVT?= =?utf-8?B?VUpHZ21sRklKQzc2UVV5VDhDNjB5Vk8wWDl2Rk5qakg1c0RKa1krMWl6elYv?= =?utf-8?B?KzZ3YXNQSllpVSt5aFdYNk9XN3AwYWUwdG9iemxYM0t5bllJMzZXNWtwRlla?= =?utf-8?B?aTNWMm1NNFBOZFkwemJYTlhBWjNBRFdDTFJDUnJiM01WQytlVnUwTStSeVc1?= =?utf-8?B?bEsyZk9lUkxGU2RwbGl0TDBxR1RaZnJPWmthN3Q4dUNoNXl5TlZhNGFDblJo?= =?utf-8?B?blhwb1VySDlKbmFFbjdmdnFGYlN3Q1QxZk50b096elE0UkVnUGI3bEJpSWph?= =?utf-8?B?cTVZRkYvdTdhOFc4YUFqNFhML0MvMmVzVWxWZ0dscTl4dnluZ0wzbmUxTlVa?= =?utf-8?B?UkVOWXJlMjNoQ1VBcDdFVTRvMVM1L3hwbUErOXdiL3N4bkNhckh1cExVUjNj?= =?utf-8?B?azM4MjZ0TFJzdGtVK29leHdjellvRVpGVmhtdnlYSmtWRC9Ba3BJWWw5S2VD?= =?utf-8?B?VXBRMWFKNmJCUXNhQk5pTlBtaEZ0ZGlEQUowZGFxR05sTVU1aVdnTHhxSXpG?= =?utf-8?B?U2RPZlJnNDJidzcycEFvNU5uSkdFM3hldWM4VHBHdG9uS2w3T0g4cDdKWG81?= =?utf-8?B?Y0dXYVJPajhtNWlCUEt4MlN3Zm9NaDVoMjU2enU1cEkxTlBPSEw4ckxSU2cv?= =?utf-8?B?OWUwT3dIWGN6ejhxc1RDMTZIZUN3aVpnaUZxOUgyNVh3ODc3UnRFS1hGenNO?= =?utf-8?Q?hqYndUnripiN7XrE=3D?= X-Exchange-RoutingPolicyChecked: VC1AGiG727+MsRVXz2jM0X4+JGXx6kRLoQBHiT8T0QGe1w3bydR0jxcLgQP052v4FvaF38RP9/R/ZgwYvtweKKX8RGRgGbYk11K14YnKyjje3oCvRWafZivhVD7RmDrksaSdG9KtTaOTPiDyqrk50aWq1txcpTuhblYdWjqwGM4rJ2OvzdpfQI/JbtNKk5exHZUN9HTw/y/BrB74KkzNfdq1n+M0m5bEZOl3FYpZ4I4Qf+j54nKu1bzsQbG+iUSq17GuPC6/VSsGlZJspgUYy8g9jCOK4QteSIpizXnIBGmztrOXnzCWOmTHyIlf7Fp6+RTtZbeNF+PaNVKmPFx0yQ== X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 194673cb-5f6e-406a-ebba-08de7eaa4c41 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2026 13:38:22.6595 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Zf3Bf9SBSwmbCgsVnEKy9q7oi9IohpFeIefcpUQcVxxwdhTTpniWQET9hRdGjQqDiRrRMAoHsPC+/tKPgN+4D0/lEByrlYLAsjJTN/wn15A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB7594 X-Proofpoint-ORIG-GUID: H5NMyzWPqve_ZK_TNNIqh3ZqV1io6nRC X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzEwMDExOSBTYWx0ZWRfX5NVCAeVVxTwv O1oxf9+tAgcEau1lwsK+fd9nmEqnlkU1RgGSGrO8aDgxijXWe376rP+EmBOGBKE1nTdT6+IYiHx lWNVOBDN8uz3UEgOiut0VDUtAvGUsBzkvwyqddNx4iDRCK5Ayq4unaWnQnAravI195+yiKkQM2V a8FDrkQNsWpkdiPZH20+ikdmSWLuVg+FnpJRYmr6CO6c7lGEOui6sflX1Sd2ww2SXZ/RNKGx+ZX 7WOUQIUOjlyB9BYlzFCQw9dyGbTcbmSUP5J/b6Oz2pZguW1E31rZwufTXuGRr4rxWhTuEmujKJh bt2W7oGi0p137UWe3eY3OMU1hO8d0ZrbdOAwIpmrhE662kwalMi2v0No0nBxsJrRIW6WZhgm0AL 0ex+sL6wBdCN3P7xSXJSJQ80qW7Vtp6X1Keuin2LwjA5hVl7+Ms36zutkhbWoCKIB0zasyD//pa 1Fqu/nuUliNJ9qkb0aw== X-Proofpoint-GUID: H5NMyzWPqve_ZK_TNNIqh3ZqV1io6nRC X-Authority-Analysis: v=2.4 cv=QppTHFyd c=1 sm=1 tr=0 ts=69b01ed2 cx=c_pps a=TnfpHwsis7t5HKTWWgh6sw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=Yq5XynenixoA:10 a=VkNPw1HP01LnGYTKEx00:22 a=bi6dqmuHe4P4UrxVR6um:22 a=iKiJcTA2PjBS6x5JeXcw:22 a=t7CeM3EgAAAA:8 a=vPYg9hmKQ9hdUfSR5Z0A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=UBFVfQAFWYhimOpKR3UA:9 a=Lip1HOFURSbzj5ta:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-10_02,2026-03-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 priorityscore=1501 spamscore=0 malwarescore=0 impostorscore=0 adultscore=0 clxscore=1015 bulkscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603100119 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 --------------VDuPUEZeP2CQ8PAOYCpPD2ou Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 >> >> 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 > --------------VDuPUEZeP2CQ8PAOYCpPD2ou Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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
--------------VDuPUEZeP2CQ8PAOYCpPD2ou--