Re: 8 bit read

[Kevin Buettner <kevinb at cygnus dot com>]

On Jul 25, 11:46am, Eli Zaretskii wrote:

> 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.)

I'm with you so far.  :-)

> 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.)

Is it possible to come up with a single number (address) which
represents ($fs:foo)?  Or does ($fs:foo) need to be represented
via two or more pieces of information in order for the low layers
to function properly?

> 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.

How does the print command know these things?

> Since the
> to_xfer_memory method accepts a `struct mem_attrib' argument, it will
> see that information, and will be able to DTRT.

I need to better understand what it means to DTRT (do the right thing).

(I'm sort of wondering if you're running into some of the same problems
that we're running into when we try to make GDB work with a Harvard
architecture.)


> 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.

I think now would be a good time for J.T. to chime in, but my
understanding of memory attributes is that one defines a number of
them (either interactively or in a sourced command file) to define how
a particular range of addresses ought to be accessed.  I.e, a
particular range of addresses might be read only in which case gdb
should never attempt to write to this memory.  Also, for some targets,
certain address ranges require that accesses occur with a certain
alignment or a certain size (byte at a time, word at a time, etc).

It sounds like you need to provide certain (alternate) access methods
for certain ranges of memory too.  It also sounds like you might need
some additional attributes that the present machinery doesn't (yet)
have defined, but once it's in, I still don't understand why you need
hooks so that other parts of GDB can define memory ranges on the fly.

As alluded to above, it may be that you're running into some of the
problems that are seen with Harvard architectures, namely that a
given address may be used to refer to more than one address space.
When this happens, it is necessary to have some means to disambiguate
such addresses.  Using memory regions for this purpose sounds like a
novel idea, but keep in mind that these regions would have to be
passed everywhere that the corresponding address (CORE_ADDR) is passed.
Also, any data structures which have CORE_ADDR members would need to
be augmented to also store the segment descriptor.  IMO, it would
probably be better to redefine CORE_ADDR to have an explicit segment
descriptor and address field.

Kevin