This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 8 bit read



On Wed, 25 Jul 2001, Kevin Buettner wrote:

> >    (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)?

No, because CORE_ADDR is not wide enough to engulf both.  Making
CORE_ADDR wider is something I'd prefer to avoid, since it will affect
Binutils as well.

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

>From the syntax of the expression whose value it is asked to print.
The special "sel:offs" form tells that there are two parts to the
address.

But if that isn't enough for `print' to know, I could even imagine a
special command, or a switch for `print', to tell it explicitly.

In other words, there's more than one reasonable way to tell `print' I
want GDB to use a special selector.  My main problem is how to convey
that info all the way to the target vector.

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

It means to use a non-default segment selector to read and write
memory.

Right now, the go32-nat.c's implementation of to_xfer_memory method
uses the debuggee's normal data segment selector.  It does so
implicitly, without being given the selector.  I can easily modify it
to use any specific selector, provided that this information is
available to to_xfer_memory when it is called.

> It sounds like you need to provide certain (alternate) access methods
> for certain ranges of memory too.

Yes.

> It also sounds like you might need
> some additional attributes that the present machinery doesn't (yet)
> have defined

Right.  But expanding the memory attributes is easy.

> I still don't understand why you need
> hooks so that other parts of GDB can define memory ranges on the fly.

Because I didn't want to burden the user with the need of defining
them interactively.  If I want to look at some data which lives on a
memory-mapped device, I don't want to have to use the "mem" command to
define the access to that memory.  I want GDB to sense automatically
that such a special access is needed, and define a memory region with
information gleaned from the expression typed by the user.

It is also possible that it would make sense to delete the region once
the command finished accessing the memory.

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

As far as I understand the design of memattr.c, you don't need to
carry that information around at all times, because the memory regions
are looked up for the attributes of the range of addresses that is
about to be accessed just before the to_xfer_memory method is called.
So any function that winds up calling to_xfer_memory will pick up the
access information on the fly.

> IMO, it would probably be better to redefine CORE_ADDR to have an
> explicit segment descriptor and address field.

Yes, but redefining CORE_ADDR is an adventure I'd like to avoid ;-)

Btw, is there any provision in GDB to add a constant to each address
recorded in the debug info, so that CORE_ADDR holds addresses with
that constant added?  (In the case of DJGPP, that constant is the base
address of the data segment, and is only known at run time.)

If this is possible, I could use linear addresses instead of offsets
from the segment's base, and then CORE_ADDR would be wide enough to
hold addresses outside the data segment as well (assuming they all
belong to a single Page Directory).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]