Mail Archives: djgpp/2001/06/01/15:30:10
"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> writes:
> > From: Nate Eldredge <neldredge AT hmc DOT edu>
> > Newsgroups: comp.os.msdos.djgpp
> > Date: 31 May 2001 23:58:24 -0700
> > >
> > > Please define ``dump memory''. GDB generally displays memory
> > > addresses as variables; if you mean ``dump memory'' the DEBUG.COM
> > > style, then it cannot do that, even for memory that is part of the
> > > normal DS selector addressable range.
> >
> > What about the `x' command? That certainly can dump memory in a
> > format rather like debug's.
>
> Not without some tricky use of GDB advanced features, such as
> ``artifical arrays''.
Huh? A command like
x/32x 0xaddress
doesn't seem especially tricky or advanced to me.
Well, maybe it will help the poster anyway.
...
> > I suspect you can sort of cheat to dump memory in other selectors. I
> > haven't tried this, but here's an idea:
> >
> > set $p = start_address
> > while ($p < end_address)
> > print/x _farpeekb(selector, $p++)
> > end
>
> I don't think this will work: _far* functions expand into inline
> assembly, so GDB will think they don't exist in the executable.
But out-of-line versions exist in the library, and the code snippet I
posted should force them to be compiled in.
> Anyway, whether or not this is appropriate for accessing memory
> through other selectors depends on the intended usage. Without the
> details from the OP, I cannot tell.
True. It was just a thought.
--
Nate Eldredge
neldredge AT hmc DOT edu
- Raw text -