This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: Move symfile.c:generic_load()? Was: RFA: patch to remote.c for larger download packet support (part 1)
- To: Stan Shebs <shebs at cygnus dot com>
- Subject: Re: Move symfile.c:generic_load()? Was: RFA: patch to remote.c for larger download packet support (part 1)
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 15 Oct 1999 14:18:43 +1000
- CC: gdb-patches at sourceware dot cygnus dot com, fche at cygnus dot com
- Organization: Cygnus Solutions
- References: <199910141510.IAA11643@andros.cygnus.com>
Stan Shebs wrote:
>
> Date: Thu, 14 Oct 1999 17:31:41 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
>
> Before I start on that patch (generic_load needs serious surgery) I'm
> wondering if the entire function hould simply be moved to remote.c or
> target.c, remote-load.c, generic-load.c, remote-utils.c?
> I contemplated this once upon a time, and decided to leave it where it
> is. It's certainly not appropriate for remote.c because it's used
> with many different protocols, remote-utils.c is a bunch of old junk
> that ought to be deleted, target.c is really for target vector
> manipulation, not random code. generic_load is nearly unique in that
> it is a file-manipulating function that does not use symbolic info,
> but it's just one function and not even that complicated, so why
> bother to create a new file just for it?
Good - I'm not the only one looking at remote-utils.c and wondering what
it is for :-) I could always empty remote-utils and then re-fill it
with generic_load :-)
The underlying reason for wanting to move it is that, as part of the
cleanup, several new ``set ...'' variables will be added:
o generic chunk size
For a cap on the size of each
download.
Value > 0 caps the size of each
transfer (in bytes) when downloading
a program.
Value <= 0 results in downloads
attempts to download entire sections
in single hits.
Actual download packet size being affected
by things like protocol limitations and
of course the dcache.
o verify download
To, at run time, enable/disable
the verification of a download.
The code for those commands is begging to _not_ be put in a symbol file
:-)
> When you've worked out the names and properties of the user-settable
> variables, it would be useful to send that by so people can see if
> there are enough hooks to make it work with their systems.
I'm open to suggestions:
``set remote download-chunk-size N''
``set remote download-veriry [0/1]''
``set download chunk-size''
``set download verify''
?
Andrew