Message ID | 20170207212450.2232-1-simon.marchi@ericsson.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 74033 invoked by alias); 7 Feb 2017 21:25:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 74022 invoked by uid 89); 7 Feb 2017 21:25:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1395, target_ops, ptid, *self X-HELO: sesbmg23.ericsson.net Received: from sesbmg23.ericsson.net (HELO sesbmg23.ericsson.net) (193.180.251.37) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Feb 2017 21:25:07 +0000 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 94.A4.27784.F2B3A985; Tue, 7 Feb 2017 22:25:04 +0100 (CET) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 7 Feb 2017 22:25:03 +0100 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from elxcz23q12-y4.ca.am.ericsson.se (192.75.88.130) by AM3PR07MB386.eurprd07.prod.outlook.com (2a01:111:e400:8820::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 7 Feb 2017 21:25:01 +0000 From: Simon Marchi <simon.marchi@ericsson.com> To: <gdb-patches@sourceware.org> CC: Simon Marchi <simon.marchi@ericsson.com> Subject: [PATCH] Fix usage of inferior_ptid in two thread_alive implementations Date: Tue, 7 Feb 2017 16:24:50 -0500 Message-ID: <20170207212450.2232-1-simon.marchi@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: BN6PR17CA0022.namprd17.prod.outlook.com (2603:10b6:404:65::32) To AM3PR07MB386.eurprd07.prod.outlook.com (2a01:111:e400:8820::12) X-MS-Office365-Filtering-Correlation-Id: 0237bc97-9c66-4d24-e954-08d44f9fc6fd X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM3PR07MB386; X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB386; 3:ofIS22FkRy0Rxz8qEmA6ifHSqPzqimFZeD/k2UJ2qV/Z+r9hBY2IJ+imuiA7CIaTdSSxFec3vobqQF0kLGOj4CDqbo3PhIToBkix3JFtivOsaA+tLIDIob3NHFsVTfA27HYjz5RnuEueVxt/B/hRxe27g5yYYxzwoQ0hs3RBexkt9QMdCVIwJioeRFI1bmM5OqsfP0qsSNoeLyYeJ55bllhDo7uWWIWSBoTdNxYatiz2uzibwHSdWqVOzVMz2/5rR101zmnx7f7udqcQX+NQbQ==; 25:L2SqQgQTTBlyLYao1OexyXlmCc1peKTfBcrP//N+sWaFPa/l07nsleaX5DzEhTZ4MSLAbYMScw9My94sH6nEysKwZ2XhTFtXOpR7hzkxrXAtSwXKe9rgy3rO+ivcbQevgdZm32CjAJJ13gms+oeIlzKWiniBYM8cM/pHm92Ni87sNTcNp9Wmi+eeUTFWXSpZC4gPtDI8lu9vQqscSoDhngTbVdOfpCP228P4ZO12jcIJYgWtQ9YnY+Za6qnUlE/hoDoUiQYTiAtbyG/YWmNTi1B2v7czJDlYd60r0KIexpgKI0k1vzGEpKvo+uhnso4kv4Nb7bX2lIAetPmEIKKX/J8KIYkwI1mtut174A/r1Is9s4tOONzjL73mCj9ziuXb3RLiAXUHuXFZXxJF3hcIcCb2EL+W0GKu8Zdsj9BiyzynNAiLMSWOgdheVZAaP6RdIFBzoj6biGdDRZYwCUBJTg== X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB386; 31:cwTYjG4DeULKNAkKBtrkTRAbykS0ybo34WoaHIzBzbku7eWvVAcmlPU3z7H69FQDF5CaQualjGgVtXiEG3sR19hobbqlCTKAZRGzpwcB7v2cSpcFyOhama89UW+z3x68V0KV9zIIVzC3LJWeEH4FwoKJ6LKQf8sc5A0Ej4vd79O+tbinitXku3giURt/HGOvdZRzjfWq18g/lrhOIREXBN2dTi4HFQy7pH6t65K7ioeVlNhmCfotRE3lc3i8HIJDjtLzlI5e5cZTzcCtt5swWA==; 20:XNK47KPU0okU33mK1UfLOLsmxNKkj2AzYeFusDRJq/WEo5bT8eVprPZL732TXC4V2/OVb7h0m/RAn2I4K3KWKUtUbw7yj7S/2iGGj/8sR9z8qALiik03IZl4hvY9XUvwIkNOX2ZXl4JKzH8Bzm3xjft1jpytfEiujw31/b3cInZqZQPeB1mGHJCKiHeCJ20TyMnz9kEguXjJj1PzCx5MSI9tZ7nQqDESsG3T1SH5cmQVgT/CR5MH3TWHq2MtEwZz6lLKBfsx2o1R8jPA4MrPhWOXdhw7sLmLaZQhGkdS6DK4ZeKxFctzrZw8dFhqJXkLzqy84nQRKCWowD/1H3TUDYZ/7cdCKIOUyes0VQBvIGDM19WPr7xbY7UBbEzLIyo9xMRSq7npb1mTT7Ti/F6lSZ0xwBcvnlVX8xhIKm4lXQ/vAifwGXX/SwDu4p2/Hh0dnbDdxUG2/XEfF5oqcOTqRa9ku9t18xi+2Yt6mWy3FsHVKLIf27dkSgRQALQh375z X-Microsoft-Antispam-PRVS: <AM3PR07MB3862C2C163CC65C42A91E4AED430@AM3PR07MB386.eurprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(2017020603029)(8121501046)(5005006)(20170203043)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(20161123562025)(6072148); SRVR:AM3PR07MB386; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB386; X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB386; 4:itNeWvSNb6P8Xk+AmwP5Hn4B7+wNeMomWq45kli6j2YOjt0bMRFFkgNnERfvtEqUkmFNoXPOvWiCu5kOPoduQCCrgbw6OhmBm2tqYc5S//patGTOQp1GDyeW56pUPxAHg+BwjNhIurGLCrdZqoRQJHcBE7LOrBXQReghkHnPnYPlcChDbp1IBClARnM6embWsG/0zzHDi5Mtz7SqkuUZ3XfsNmZZ8P7iThYBfx7EI8kY2RlT9oxxRP3S2lSyh04mP5kFyj7wqJlXppWg3C1yF9j7n7ivB1NLTnQOdEwaHh/O3Ukqv6vx8xQjuHjoJtv/EyyWpGNVt+WP7BoQuaP+lc1MCQ3BUTzhFagu0IeIBeNWEy7DicL3zheXx3y1Bulq+7ycHoJP6HKe993qBci9ZYpbfhPQP1sYuan095xEKO2e7sHlp3OQ5yYUnNCcipPJ1lC+cGLip8xChDJbDjYyPK3v5V43XTvaJwKygwKl8E4xc4ZsRoi1ljNDXh5wHDbHrJPciX1PoXC5V5xUS88D/i3jqymwFU1CeLqQS5LXVPKpgslvSPpFonPsV+Z/iBoUdCW4RP5+8iaYMfJhhNg4wIV7XaUI5/mqXdNYJjlxi4qMexi2aqp3YRLfRxmnlzMALrZ83LYglMvdUCh/ekFluNS5T6I8zZnQB8TnFOPGx7I= X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(39450400003)(189002)(54534003)(199003)(3846002)(97736004)(6116002)(5003940100001)(92566002)(1076002)(50986999)(33646002)(86362001)(189998001)(101416001)(53936002)(4326007)(2351001)(450100001)(105586002)(106356001)(47776003)(66066001)(2906002)(7736002)(42186005)(305945005)(6486002)(68736007)(50466002)(81156014)(81166006)(50226002)(36756003)(8676002)(48376002)(38730400002)(5660300001)(110136004)(107886003)(6916009)(6506006)(6666003)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB386; H:elxcz23q12-y4.ca.am.ericsson.se; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3PR07MB386; 23:KnXdm4WpjvZssHS0+N1oVynG+Qdk2WvukSza118Xn+?= =?us-ascii?Q?0dW5djCsOq97i0NOQd+j9EoEcGonlf7T1/AdHdcVCDsihE0OkkK81fZPnhFE?= =?us-ascii?Q?Bin7Fl7blU3UhCdPUWe8BfTwt0IxnsfH3nvY2CbRE8MjQ1virqUjnN6XMBSU?= =?us-ascii?Q?0Yygio9MeTLmck5g0gTPT0aqWAhz66/8qyrfQy1fLZ8bOa+iGSCpJycEEAQz?= =?us-ascii?Q?1JooEvrnLriKzw1nMed7CkflCMfA1pAmr8G30yZJPu/kKDcWFXk8W273Lt4C?= =?us-ascii?Q?7ELH4dlB5rXAWLudySSwm4CLlr2uHOrUaAWUt+48/NqKKu/Umfw8WAEJL5k9?= =?us-ascii?Q?ojCrv+k/qqldf+obtVopVZQdjD1L0UNqE91CxgOSWlq1lsBlXVwKoe3+DgIg?= =?us-ascii?Q?aq3QGMV5VI/RYgLdti1XVP6yq1k4gZF6n/Y9DQN7hRmq/OEd+uO5Rn+sbDF2?= =?us-ascii?Q?CTdUkFAvIEBubgnCaMD9a2c2st2ANEMQ3eKwjWQkwL3xevRwszfIvqzudSTf?= =?us-ascii?Q?qSKpxHgKfbCNc7xea7ONe0UKGA9wG5S4RS+qM95xDpU2RYU0/BbtRFriDCGG?= =?us-ascii?Q?rSc9IpSOPtXzE77YU627KIBi30WsXyREypWmiZ5EIiA5xVyk8JONCKqZxClj?= =?us-ascii?Q?buRfUIBp6OVtEkwf8xi6gcY44TysVV0djVALXvnLneughtn7XEnw7J8NEvUC?= =?us-ascii?Q?kjhFb1WLVaPwaVOURCYDBayHHIiD7t78VYPujkfokafg5N2EX0JDRIcJ4fh7?= =?us-ascii?Q?EbAS3XTKNBI5hAwfTg5zr67jcPTz2Ek9qSR53W/WTQ+6qTasMclCFl8VKJ/7?= =?us-ascii?Q?OKRhMQifcW5Ahe8jAvyyF1viKVP8m2+ibUILiUCx1b4xQ3weyzS+SOXLw4EL?= =?us-ascii?Q?ix2YaWw7EYHXJ9YLZzhHPV/HCORqjZ5YT5tNhn8t7qEXBnA7guQazPQincch?= =?us-ascii?Q?FcmEhM2L8RkY+RQ6kmncQGWbXXjCfz7ap/Lq6pNZD+dAJxY308SO7t+bU+zh?= =?us-ascii?Q?04uA6NXHnFL4Vror56obAopxrx1bd1A7j1XWHBBakMvdSX/BxVGZ86/eRmMI?= =?us-ascii?Q?R+62VnfHULpImA4hEG4bO1aZVGn3Jd3KdQpK7LNfEwg9JUqyVta5Py22r2Zw?= =?us-ascii?Q?yHXmRigVowNuPTOJwK/RoLSuOSLa6Q?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB386; 6:73JT8CjSiljMvn2iIckW7exEcRRoGgmjBGKMFfnGjzIMuLY0iCxT21/pq2FUVt1LOvOFEoQb6+76y586HJFpCOHc74DzIyg+WC+vY9eynKgasxaapGHduVUX3UOPlzrgfAY5sk4SYJqLwHw/ShBHry3IDBr4mCdWxnEIzeSbOBS+D4cW1BRN8v2k2z7uMWwfpgHV8iMG6WQBNbLclabsRwuK/awkY8Q5TLbpm5ThpbUVVHWaOqUnIECTbNzTCrAiosI+lkxOMeAhrpPnJkgLpHsysc+vCbCY3LZCQkc8AN4BHl678YS1Qps9p+okmvt5NmVL1PyhnDWcepioJtG1YqjuSANBlnPe1myOGWGXgtm0xWh3BnsdwSExAeg66yedaACNcz09z1PjXFATURoX8Q==; 5:OP6azQH3O5A8R7mRVH9tdjCuO7T3cYo0xWDxeHigW5o0zsMLi+khudCfaZQ5ZyYhL105rHZiug8RvKto7G1fpRhdteUhJY1SIkob3RLdo0WzGlWrMJoFUTeUDz0bVThX3AuzxXT/tfTSceV36gM2lg7Y6jOc/jZCLIuDPKMOjvk=; 24:7Dq5VpCLhALROflQM4kElPJXKVkveRDJS7Vf37OwmXZxe9Dpy7bekWkBiwfNVrRzWH9vhly8dvzI+EUs+YdV4p3i60AWUxOQMhmbpuFs+3c= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB386; 7:7ICNXAe9zyltt2k/Eks4Hm727+lZbzaNBnW8qbzDRPqGdP97HGOSqdwyQ/4nXfbjCTRhqABZBo3eJtGTCGuZsO5j+BxkhQB9eOJx5N83nbd5bi3yFNnoL8CXhqEUEA+5dNWcScMAiE/mqPUfYs7grlM2M6qKBR4Hxci+hK+p23q11InAqVFWmrfiNpqMkFLj8JXUnZ4d2CYqDFYxWYsbMP/cOKWwVYH7itiQveVf8U6AHiUJCuARSpJtP8FmdHX6CNCuBKibiBiWBGdAmSRC8AePh8TJRShUXJYErfs0HTvDkARoKTn9WQAbbbKWORPb9xcA9dtz6BnRb2LQNtlopTD60oXRZv9aIsl8hes5jtIUDlbTc+8TbS5NAtWdFQgRT2oIFECv2VBRfVuMPeWvh4lgJ043jwY4rv+eDQgf6iJV5ejtWNU1QAhfZKJR02FQoZJ2HKmVApoFgStQ4Q19rUSaF5IaoDZDcioLxaExoIj+j4/bSG4OMm2/eS/hw/YNjPNx68JZMuDDut3/Dvesww== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2017 21:25:01.8552 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB386 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes |
Commit Message
Simon Marchi
Feb. 7, 2017, 9:24 p.m. UTC
While inspecting some target code, I noticed that in these two implementations of thread_alive, inferior_ptid is referenced directly instead of using the ptid passed as parameters. I guess that it is wrong, although I can't really test it in both cases. gdb/ChangeLog: * bsd-uthread.c (bsd_uthread_thread_alive): Use ptid instead of inferior_ptid. * go32-nat.c (go32_thread_alive): Likewise. --- gdb/bsd-uthread.c | 2 +- gdb/go32-nat.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Comments
On 02/07/2017 09:24 PM, Simon Marchi wrote: > While inspecting some target code, I noticed that in these two > implementations of thread_alive, inferior_ptid is referenced directly > instead of using the ptid passed as parameters. I guess that it is > wrong, although I can't really test it in both cases. I can't test either, but it looks right to me. Thanks, Pedro Alves
On 2017-02-08 07:40, Pedro Alves wrote: > On 02/07/2017 09:24 PM, Simon Marchi wrote: >> While inspecting some target code, I noticed that in these two >> implementations of thread_alive, inferior_ptid is referenced directly >> instead of using the ptid passed as parameters. I guess that it is >> wrong, although I can't really test it in both cases. > > I can't test either, but it looks right to me. Soooo.. is this an approval :) ?
On 02/09/2017 04:46 PM, Simon Marchi wrote: > On 2017-02-08 07:40, Pedro Alves wrote: >> On 02/07/2017 09:24 PM, Simon Marchi wrote: >>> While inspecting some target code, I noticed that in these two >>> implementations of thread_alive, inferior_ptid is referenced directly >>> instead of using the ptid passed as parameters. I guess that it is >>> wrong, although I can't really test it in both cases. >> >> I can't test either, but it looks right to me. > > Soooo.. is this an approval :) ? OK by the end of the week to give a chance of area maintainers or interested folks to comment. E.g., Eli is the go32-nat.c maintainer and I don't mean to overstep, though that bit does look obvious to me. Mark or someone with BSD access could want to comment on the BSD bit. The latter you could perhaps test on the compile farm, if you have access. Thanks, Pedro Alves
> Cc: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org > From: Pedro Alves <palves@redhat.com> > Date: Thu, 9 Feb 2017 17:53:16 +0000 > > On 02/09/2017 04:46 PM, Simon Marchi wrote: > > On 2017-02-08 07:40, Pedro Alves wrote: > >> On 02/07/2017 09:24 PM, Simon Marchi wrote: > >>> While inspecting some target code, I noticed that in these two > >>> implementations of thread_alive, inferior_ptid is referenced directly > >>> instead of using the ptid passed as parameters. I guess that it is > >>> wrong, although I can't really test it in both cases. > >> > >> I can't test either, but it looks right to me. > > > > Soooo.. is this an approval :) ? > > OK by the end of the week to give a chance of area > maintainers or interested folks to comment. E.g., Eli > is the go32-nat.c maintainer and I don't mean to overstep, > though that bit does look obvious to me. Is that function even called in the go32 port?
On 2017-02-09 15:46, Eli Zaretskii wrote: >> Cc: Simon Marchi <simon.marchi@ericsson.com>, >> gdb-patches@sourceware.org >> From: Pedro Alves <palves@redhat.com> >> Date: Thu, 9 Feb 2017 17:53:16 +0000 >> >> On 02/09/2017 04:46 PM, Simon Marchi wrote: >> > On 2017-02-08 07:40, Pedro Alves wrote: >> >> On 02/07/2017 09:24 PM, Simon Marchi wrote: >> >>> While inspecting some target code, I noticed that in these two >> >>> implementations of thread_alive, inferior_ptid is referenced directly >> >>> instead of using the ptid passed as parameters. I guess that it is >> >>> wrong, although I can't really test it in both cases. >> >> >> >> I can't test either, but it looks right to me. >> > >> > Soooo.. is this an approval :) ? >> >> OK by the end of the week to give a chance of area >> maintainers or interested folks to comment. E.g., Eli >> is the go32-nat.c maintainer and I don't mean to overstep, >> though that bit does look obvious to me. > > Is that function even called in the go32 port? Why wouldn't it? For example, you could have this pseudo-stack: #0 go32_thread_alive #1 target_thread_alive #2 thread_alive #3 thread_apply_all_command If this target doesn't support multiple threads, it's possible that inferior_ptid will always be equal to ptid (equal to the only existing thread). But still it would be "more correct" to read the parameter instead of the global, IMO. Simon
> Date: Wed, 22 Feb 2017 16:06:50 -0500 > From: Simon Marchi <simon.marchi@polymtl.ca> > Cc: Pedro Alves <palves@redhat.com>, simon.marchi@ericsson.com, > gdb-patches@sourceware.org > > > Is that function even called in the go32 port? > > Why wouldn't it? For example, you could have this pseudo-stack: > > #0 go32_thread_alive > #1 target_thread_alive > #2 thread_alive > #3 thread_apply_all_command > > If this target doesn't support multiple threads, it's possible that > inferior_ptid will always be equal to ptid (equal to the only existing > thread). Go32 indeed doesn't support multiple threads. > But still it would be "more correct" to read the parameter instead > of the global, IMO. I didn't say anything to the contrary. I'm saying that if go32 doesn't have this function called, I don't have to worry about the implications of the change.
On 2017-02-22 22:34, Eli Zaretskii wrote: >> But still it would be "more correct" to read the parameter instead >> of the global, IMO. > > I didn't say anything to the contrary. I'm saying that if go32 > doesn't have this function called, I don't have to worry about the > implications of the change. Well, I'm saying that go32 _can_ have this function called. So you should worry about the implications :). Anyhow, given that go32 doesn't have multiple threads (thanks for confirming), the patch shouldn't have any practical impact, so I've pushed it. Thanks, Simon
On Thursday, February 09, 2017 05:53:16 PM Pedro Alves wrote: > On 02/09/2017 04:46 PM, Simon Marchi wrote: > > On 2017-02-08 07:40, Pedro Alves wrote: > >> On 02/07/2017 09:24 PM, Simon Marchi wrote: > >>> While inspecting some target code, I noticed that in these two > >>> implementations of thread_alive, inferior_ptid is referenced directly > >>> instead of using the ptid passed as parameters. I guess that it is > >>> wrong, although I can't really test it in both cases. > >> > >> I can't test either, but it looks right to me. > > > > Soooo.. is this an approval :) ? > > OK by the end of the week to give a chance of area > maintainers or interested folks to comment. E.g., Eli > is the go32-nat.c maintainer and I don't mean to overstep, > though that bit does look obvious to me. Mark or someone > with BSD access could want to comment on the BSD bit. The > latter you could perhaps test on the compile farm, if you > have access. [ Apologies for the late reply ] I don't think any modern versions of either FreeBSD or OpenBSD use bsd-uthread.c. The uthread target is for a thread implementation that only provided threads in userland on top of a single process (like "green" threads in the JDK). FreeBSD last shipped a release with support for this thread model (FreeBSD 6.4) in 2008. I can't speak to when OpenBSD stopped using user-based threads, but the existence of kernel-based thread support in the obsd-nat target implies it isn't used anymore either. For FreeBSD at least I think it would be fine to remove bsd-uthread.c. (I should also send a patch in to remove FreeBSD/alpha as that platform was retired at around the same time. The last release to support alpha was 6.3 also released in 2008.)
On 2017-03-29 15:32, John Baldwin wrote: > I don't think any modern versions of either FreeBSD or OpenBSD > use bsd-uthread.c. The uthread target is for a thread implementation > that only provided threads in userland on top of a single process > (like "green" threads in the JDK). FreeBSD last shipped a release > with support for this thread model (FreeBSD 6.4) in 2008. I can't > speak to when OpenBSD stopped using user-based threads, but the > existence of kernel-based thread support in the obsd-nat target > implies it isn't used anymore either. For FreeBSD at least I think > it would be fine to remove bsd-uthread.c. > > (I should also send a patch in to remove FreeBSD/alpha as that > platform was retired at around the same time. The last release > to support alpha was 6.3 also released in 2008.) Thanks for the reply, this is very valuable information. I would appreciate very much any effort to remove obsolete targets, as it has some maintenance cost. For example, doing refactors that require touching all the targets (such as changing the interface of a target_ops method) is very long. If we can remove any target that has no reason to be today, it can only help. Simon
diff --git a/gdb/bsd-uthread.c b/gdb/bsd-uthread.c index 41c7d59be1..20eecd3879 100644 --- a/gdb/bsd-uthread.c +++ b/gdb/bsd-uthread.c @@ -401,7 +401,7 @@ bsd_uthread_thread_alive (struct target_ops *ops, ptid_t ptid) { enum bfd_endian byte_order = gdbarch_byte_order (target_gdbarch ()); struct target_ops *beneath = find_target_beneath (ops); - CORE_ADDR addr = ptid_get_tid (inferior_ptid); + CORE_ADDR addr = ptid_get_tid (ptid); if (addr != 0) { diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c index 3e9e99f068..1fca8e2e53 100644 --- a/gdb/go32-nat.c +++ b/gdb/go32-nat.c @@ -938,7 +938,7 @@ go32_terminal_ours (struct target_ops *self) static int go32_thread_alive (struct target_ops *ops, ptid_t ptid) { - return !ptid_equal (inferior_ptid, null_ptid); + return !ptid_equal (ptid, null_ptid); } static char *