From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27696 invoked by alias); 7 Feb 2007 21:47:55 -0000 Received: (qmail 27686 invoked by uid 22791); 7 Feb 2007 21:47:54 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 Feb 2007 21:47:45 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.0/8.14.0) with ESMTP id l17LlcTv031473; Wed, 7 Feb 2007 22:47:38 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.0/8.14.0/Submit) id l17LlbVU013575; Wed, 7 Feb 2007 22:47:37 +0100 (CET) Date: Wed, 07 Feb 2007 21:47:00 -0000 Message-Id: <200702072147.l17LlbVU013575@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: dewar@adacore.com, Wiljan.Derks@zonnet.nl, gdb@sourceware.org In-reply-to: <20070202173456.GT17864@adacore.com> (message from Joel Brobecker on Fri, 2 Feb 2007 09:34:56 -0800) Subject: Re: How to tell gdb about dlls using remote protocol References: <003f01c7457c$0f2d8090$9600000a@kamer> <20070131223113.GA15122@nevyn.them.org> <20070201175311.GG17864@adacore.com> <20070201225437.GA13740@nevyn.them.org> <20070201230301.GM17864@adacore.com> <20070201235944.GA16114@nevyn.them.org> <45C2D80E.2050403@adacore.com> <20070202114312.GA15239@nevyn.them.org> <20070202165155.GS17864@adacore.com> <20070202165619.GA30801@nevyn.them.org> <20070202173456.GT17864@adacore.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00043.txt.bz2 > Date: Fri, 2 Feb 2007 09:34:56 -0800 > From: Joel Brobecker > > > Hmm, perhaps it successfully gets you out and only misses frames. I'm > > pretty sure I remember that when debugging a Windows build of GDB, the > > select helper threads live somewhere in NTDLL without a valid frame. > > I am not sure about that particular thread. But for the other ones, > we are indeed counting on the fact that all we lose is skipping one > frame. > > > I'd be curious to see it, at least, but I'm not sure what we can do. > > Here it is. The diff is probably malformed, because I had to remove > a couple of patches we backported from head, but that should give > you the idea. I wouldn't be too thrilled to have this Windows-specific code in the generic i386-tdep.c.