From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14311 invoked by alias); 30 May 2003 13:03:48 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14234 invoked from network); 30 May 2003 13:03:47 -0000 Received: from unknown (HELO sun.netezza.com) (209.113.240.37) by sources.redhat.com with SMTP; 30 May 2003 13:03:47 -0000 Received: from astral (host20 [192.168.0.20]) by sun.netezza.com (8.12.9+Sun/8.12.9) with SMTP id h4UD3kTA027799; Fri, 30 May 2003 09:03:46 -0400 (EDT) Message-ID: <0f5001c326ab$e7e95ec0$1400a8c0@astral> Reply-To: "John S. Yates, Jr." From: "John S. Yates, Jr." To: "Paul Koning" Cc: "gdb" References: <0eb201c325e9$5fb63450$1400a8c0@astral><20030529152702.GA10363@nevyn.them.org><0ec201c325fb$764554a0$1400a8c0@astral> <16086.16988.657059.717389@pkoning.dev.equallogic.com> Subject: Re: malloc in inferior Date: Fri, 30 May 2003 13:03:00 -0000 Organization: Netezza Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-05/txt/msg00413.txt.bz2 From: "Paul Koning" Sent: Thursday, May 29, 2003 1:24 PM > Are you talking about remote target debug? I don't know of anything > that uses malloc in the remote target protocol implementations I've > seen. That ignores function call (which I've never used, it doesn't > seem to work in any implementation I've ever worked on). Paul, I work in an environment with a number of senior engineers each with decades of experience doing OS and embedded systems work. An informal poll indicates that none of them has ever seen gdb's function call capability work reliably. On reflection I think that this is because RSP hides from the stub the fact that a continue is being performed on behalf of a gdb call versus an actual continue of the stopped application. These users' typical expectations are that a gdb call should be utterly uninvaisive (principle of least astonishment). This is why the gdb stub executes in exception context with interrupts disabled. Having a call to a debug dump utility restore full thread context including reenabling interrupts, triggering who knows what churning of carefully inspected state, makes gdb's call capability just too risky for these developers. This only makes invisible gdb calls even more pernicious. Some of the developers I talked to were aware of the malloc behavior thought none were able to articulate precisely the conditions under which it occurs. They simply chalk it up to gdb flakiness and restrict themselves to some collection of debugging actions that experience has shown to be reliable. /john