From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10831 invoked by alias); 12 Mar 2003 18:15:03 -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 10823 invoked from network); 12 Mar 2003 18:15:02 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 12 Mar 2003 18:15:02 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2C1742B11; Wed, 12 Mar 2003 13:15:02 -0500 (EST) Message-ID: <3E6F7926.2070603@redhat.com> Date: Wed, 12 Mar 2003 18:15:00 -0000 From: Andrew Cagney 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 Cc: Michael Elizabeth Chastain , stcarrez@nerim.fr, brobecker@gnat.com, gdb@sources.redhat.com, kettenis@chello.nl Subject: Re: 8-byte register values on a 32-bit machine References: <200303021659.h22Gxc908446@duracef.shout.net> <3E6F53B3.6010803@redhat.com> <20030312155116.GA3669@nevyn.them.org> <3E6F670D.4030205@redhat.com> <20030312170052.GA31979@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00186.txt.bz2 >> > I think it is very dangerous. It's assuming a specific algorithm >> > in the compiler. That locks both GDB and GCC into something of a >> > death spiral. I think its far better to try and get a proper >> > location mechanism working. > >> >> There are other ways forward on this - moving the algorithm to libiberty >> (like the demangler). > > > This is a target-specific allocation order, for communication between > GCC and GDB, not a matter of published interfaces - I don't think it > belongs in libiberty. It's subject to change, but I have a reasonable > expectation that it won't change until after debugging info to express > it is available. > > In any case I'm going back to working on locations as objects, which is > the next step in fixing this properly. Mark's point was that the algorithm, while machine specific, hasn't changed in N (10?) years. Even if in the future, the algorithm does change, GDB/GCC might as well share the code for the original one so that GDB can work better with older compilers. Andrew