From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-13342-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 4684 invoked by alias); 8 Apr 2003 20:51:21 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 4673 invoked from network); 8 Apr 2003 20:51:19 -0000
Received: from unknown (HELO localhost.redhat.com) (207.219.125.105)
  by sources.redhat.com with SMTP; 8 Apr 2003 20:51:19 -0000
Received: from redhat.com (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id 4337E2B23; Tue,  8 Apr 2003 16:51:09 -0400 (EDT)
Message-ID: <3E93363D.90409@redhat.com>
Date: Tue, 08 Apr 2003 20:51:00 -0000
From: Andrew Cagney <ac131313@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Richard.Earnshaw@arm.com,
	"Thomas,Stephen" <stephen.thomas@superh.com>,
	Geoff Keating <geoffk@geoffk.org>, gdb@sources.redhat.com,
	"McGoogan, Sean" <sean.mcgoogan@superh.com>
Subject: Re: memset (0, 0, 0);
References: <9FF3133289A7A84E81E2ED8F5E56B379604386@sh-uk-ex01.uk.w2k.superh.com> <200304080929.h389TuE03840@pc960.cambridge.arm.com> <20030408132559.GA24135@nevyn.them.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-04/txt/msg00074.txt.bz2

> It looks as though that implementation of xmalloc doesn't match the 
>> general specification of xmalloc, which is that xmalloc must *never* 
>> return NULL (see libiberty/xmalloc.c for the specification).
>> 
>> I'm not sure why gdb is trying to provide its own implementation of these 
>> functions and not use those in libiberty.  Andrew?
> 
> 
> The ones in libiberty call exit; the ones in gdb call error() and
> unwind cleanups.  GDB prefers not to abort when it runs out of memory,
> esp. if it can just abort the current operation and reclaim memory.

The other reason is that, optionally, they need to be routed through to 
  mmalloc() calls.

Anyway, it should be pretty clear that the real problem here is that 
something was lost in the liberty/xmalloc -> gdb/xmalloc translation (I 
suspect that there was a debate way back when and it forgot to take 
liberty's xmalloc's `well defined semantics' into account).

I'll check in a `fix'.

Andrew