Date: Fri, 01 Jun 2001 11:23:11 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: Nate Eldredge <neldredge AT hmc DOT edu>
Message-Id: <3405-Fri01Jun2001112310+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp AT delorie DOT com
In-reply-to: <831yp4wusv.fsf@mercury.bitbucket> (message from Nate Eldredge on
	31 May 2001 23:58:24 -0700)
Subject: Re: GDB and FSDB - getting x86 specific info (page tables, ldt, gdt)
References: <000b01c0ea24$55501dd0$e70610ac AT speakeasy DOT net> <2593-Fri01Jun2001085054+0300-eliz AT is DOT elta DOT co DOT il> <831yp4wusv DOT fsf AT mercury DOT bitbucket>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> 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''.  And the output doesn't look like the hex dump
some people are used to see in other debuggers.

That's why I asked for a definition of ``dump memory''.

> > As for other selectors, I don't think you can do that currently.  If
> > you have specific needs, there might be a way to do something, so
> > please consider telling what memory do you need to dump and why.
> 
> 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.

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.