From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51364 invoked by alias); 11 Aug 2016 00:39:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 63423 invoked by uid 89); 11 Aug 2016 00:17:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=our, opening X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 11 Aug 2016 00:17:40 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7FB3CA89A; Thu, 11 Aug 2016 00:17:38 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7B0HbKt020677; Wed, 10 Aug 2016 20:17:37 -0400 Subject: Re: Program-assigned thread names on Windows To: LRN , gdb-patches@sourceware.org References: <5052d495-ea40-b364-96ea-9e68c90bd747@gmail.com> <0cabec98-8411-2c3a-98d0-3d950de02bc5@gmail.com> <28023f06-f99c-77d1-10cf-5243f2a082a4@gmail.com> <0e59216f-77cb-608a-aa39-578c2610eda1@dronecode.org.uk> <0f064b2b-6b51-f132-caa6-a4c1a85585a3@gmail.com> <2c9f43ec-af6f-cdaf-8e45-b251588b9b89@gmail.com> <0515957c-dfd2-b119-d423-517917e8a5cd@gmail.com> <40aaee01-35a5-9d3f-ceae-2bf4ca53a7b9@gmail.com> <83twf3md9t.fsf@gnu.org> <96ea9dc1-ce52-532d-d733-97af33bb70b4@gmail.com> <9f602f70-b7de-7433-dbd1-61bdc328b6a9@redhat.com> <0926f8a1-8f4b-958b-416d-52c7595b5bd8@gmail.com> From: Pedro Alves Message-ID: <17be9963-7957-ebc1-9135-dbe70da342ea@redhat.com> Date: Thu, 11 Aug 2016 00:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <0926f8a1-8f4b-958b-416d-52c7595b5bd8@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-08/txt/msg00128.txt.bz2 On 08/11/2016 12:42 AM, LRN wrote: > On 10.08.2016 21:45, Pedro Alves wrote: >> On 08/10/2016 06:54 PM, LRN wrote: >> >> Maybe I could convince you to implement this in gdbserver/win32-low.c too? > > You can't. I've never used gdbserver, and i don't see any need for me to > start using it. And since i don't use it, i wouldn't be able to test > anything code changes i could introduce there. It's as simple as: shell1: $ gdbserver :9999 testprog.exe shell2: $ gdb testprog.exe -ex "tar rem :9999" -ex "b main" -ex "c" > > TBH, i don't have any plans for further contributions to gdb. There is only > one more feature that i thought could be added (using Windows API to obtain > stack traces, enhancing the built-in gdb stack walker; thus gdb would be > able to show useful stack trace even while being deep inside W32 API > calls), but the code was so complicated for me that i've failed to even > *find* where to start. > Sounds like you'd need to write a new frame unwinder. Grep for "const struct frame_unwind .* =" to find the many instances. The IA64 one, in ia64-libunwind-tdep.c / ia64-tdep.c, is probably the closest, as that uses an external library (libunwind) to do the heavy lifting. Our Windows x64 SEH unwinder is in amd64-windows-tdep.c. I think I read that you're on 32-bit, though, right? An unwinder independent of the system one is better for being usable when cross debugging as well. I wonder whether between Microsoft's recent opening of the PDB format, and what the community might have learned in the past years itself, there's enough to avoid relying on MS APIs. I'd go look at Wine's implementation of said APIs too. Thanks, Pedro Alves