From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13940 invoked by alias); 1 May 2008 19:24:18 -0000 Received: (qmail 13930 invoked by uid 22791); 1 May 2008 19:24:18 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 May 2008 19:23:59 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id E509E3C23F; Thu, 1 May 2008 12:23:57 -0700 (PDT) Subject: Re: the "load" command and the .bss section From: Michael Snyder To: Daniel Jacobowitz Cc: gdb@sourceware.org In-Reply-To: <20080501033215.GA32600@caradoc.them.org> References: <200804270509.34308.vapier@gentoo.org> <1209406914.4615.297.camel@localhost.localdomain> <200804302010.59482.vapier@gentoo.org> <1209607380.4615.388.camel@localhost.localdomain> <20080501033215.GA32600@caradoc.them.org> Content-Type: text/plain Date: Thu, 01 May 2008 19:24:00 -0000 Message-Id: <1209669837.4615.397.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2008-05/txt/msg00016.txt.bz2 On Wed, 2008-04-30 at 23:32 -0400, Daniel Jacobowitz wrote: > On Wed, Apr 30, 2008 at 07:03:00PM -0700, Michael Snyder wrote: > > That's why there are different implementations of "load". > > A bare-metal target would presumably wind up using the > > appropriate "load" version. > > Well that's probably why historically there _were_ different > implementations of load. But I doubt it is still justified. > > Only the three m32r targets, the remote-mips target (for specific > monitors), remote-sim, and target remote have implementations of load. > It looks to me like target remote's would work for all of them except > the sim. m32r is just using a wrapper around generic_load already. > monitor and mips are using srec but could do that anyway for large > writes. Presumably, at least. But I have no way to test any of them > so I leave them alone. Right. I think there used to be more implementations, but some have probably slipped quietly into the night, along with their discontinued targets and architectures. Remote and sim are probably among the main ones that still need to be supported. Reviewing the thread -- the OP says he is bringing up a new board using jtag. I'm not clear which version of load that implies -- remote? So, given that there are only a few versions to support, instead of the plethora I was recalling (eg. we probably don't need to worry too much about a.out...), maybe there is a choice to make here, between: a) Making up a spec for the "load" command and then making sure that the remote, sim, and ??? versions all conform to that spec, or b) Just adding features such as "clear the .bss section" to the version of load that we expect to use the most (remote?), and leaving the other(s) alone.