Re: 8 bit read

[Eli Zaretskii <eliz at is dot elta dot co dot il>]

On Tue, 24 Jul 2001, Kevin Buettner wrote:

> > But the current API in memattr.c doesn't allow GDB applications code
> > to create memory regions except via the "mem" commands.
> 
> Can you explain in more detail?

I hope an example will have more success than my explanations until
now ;-)

During debugging a program, it is customary to do things like this:

   (gdb) p *(struct foobar *)foo

or this:

   (gdb) p/x *bar@num

This displays the contents of a structure or a portion of an array.
(There's nothing special about the particular forms of the print
command I've chosen to show here, it's just an example of examining
program's data.)

Now suppose that the variables foo and bar are outside the normal
address space used to store program's data.  In the DJGPP case, it
could be some memory on a memory-mapped device, or some DOS data
structure in conventional memory.  I cannot currently examine such
data with GDB, because the to_xfer_memory method only copies data from
and to the debugged application's normal data segment.

Suppose, however, that I could say something like this:

   (gdb) p/x *($fs:foo)@num

meaning that the array is at offset `foo' from the segment whose
selector is in the FS register.  (The syntax is not important; I'm not
saying that I care for this particular syntax.)  What would it take to
implement such a feature?

My line of thought was to have the `print' command create a memory
region descriptor which would hold the value of $fs, the selector
required to access the data, and maybe its limits.  Since the
to_xfer_memory method accepts a `struct mem_attrib' argument, it will
see that information, and will be able to DTRT.

In other words, my problem was how to pass the information about the
memory to be accessed from the GDB application level to the target
vector.  Memory attributes seemed like a perfect candidate.

However, for that, I need the `print' command to be able to create
memory regions with certain attributes, and we don't have an API for
that.  It was a small shock for me to see that the only way to create
regions is with an interactive user command, and that the only
exported programmatic interface is lookup_mem_region; I wonder why
would it make sense to limit access to memory attributes only to
looking up regions.  Perhaps I don't understand something about memory
regions.

Do I make any sense?