From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13482 invoked by alias); 29 May 2003 13:51:16 -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 13437 invoked from network); 29 May 2003 13:51:16 -0000 Received: from unknown (HELO sun.netezza.com) (209.113.240.37) by sources.redhat.com with SMTP; 29 May 2003 13:51:16 -0000 Received: from astral (host20 [192.168.0.20]) by sun.netezza.com (8.12.9+Sun/8.12.9) with SMTP id h4TDpGTA014752 for ; Thu, 29 May 2003 09:51:16 -0400 (EDT) Message-ID: <0eb201c325e9$5fb63450$1400a8c0@astral> Reply-To: "John S. Yates, Jr." From: "John S. Yates, Jr." To: "gdb" Subject: malloc in inferior Date: Thu, 29 May 2003 13:51: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/msg00384.txt.bz2 I have finally figured out that the reason gdb keeps crashing my embedded system is that it tries to call malloc at the drop of a hat. There are various contexts in our code where performing a memory allocation is disallowed. This is enforced by our allocation primitives. Our system does not uses malloc. The malloc that is part of the c-runtime calls through a null function pointer, triggering a machine reset. So something as simple as (gdb) print "foo" causes a crash. Why can gdb not allocate values within its own address space? I understand that to support calling functions in the inferior gdb may have to materialize values there. But these should be pushed into the inferior once it is clear that they need to exist there. And how can gdb possibly debug a multi-threaded application with a thread-safe malloc? One possibility would be to add malloc and free messages to the remote protocol. Then a stub could allocation memory in the proper address space without interacting with the inferior's environment. Another would be to have a stub provide a block of memory. A query would determine the address and size of this block. Then gdb could manage the memory entirely on its own. /john -- John S. Yates, Jr. 508 665-6897 (voice) Netezza Inc 508 665-6811 (fax) 200 Crossing Blvd. Framingham, MA 01701