Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@specifix.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb@sourceware.org
Subject: Re: the "load" command and the .bss section
Date: Thu, 01 May 2008 19:24:00 -0000	[thread overview]
Message-ID: <1209669837.4615.397.camel@localhost.localdomain> (raw)
In-Reply-To: <20080501033215.GA32600@caradoc.them.org>

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.




  reply	other threads:[~2008-05-01 19:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-28  8:02 Mike Frysinger
2008-04-28 13:48 ` Daniel Jacobowitz
2008-04-28 17:29   ` Mike Frysinger
2008-04-28 17:42     ` Daniel Jacobowitz
2008-04-29 18:04 ` Michael Snyder
2008-05-01  0:11   ` Mike Frysinger
2008-05-01  2:03     ` Michael Snyder
2008-05-01  3:32       ` Daniel Jacobowitz
2008-05-01 19:24         ` Michael Snyder [this message]
2008-05-01 19:32           ` Daniel Jacobowitz
2008-05-01 20:05             ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1209669837.4615.397.camel@localhost.localdomain \
    --to=msnyder@specifix.com \
    --cc=drow@false.org \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox