8 bit read

8 bit read

[Naushit Sakarvadia]

Hello All,

This is regarding PowerPC 8260 gdb.

My question is how do I tell gdb to read a byte only  while reading
0xfff00100..0xfff00500 address range.
While  checking mem I uze  "x /b  0xfff00100" and it works fine , but while
I do unassamble from this address it tries to read a word from this
location, and as a result the first byte is repeated 4 times.It is 8 bit
wide flash mem,so
you cant read a word at a time.

So I want to tell gdb to do byte wide reading while doing unassambling and
all other operations.

Please reply me personally, I am not on gdb mailing list.

Thanks
Naushit

Re: 8 bit read

[Daniel Jacobowitz]

On Mon, Jul 23, 2001 at 11:03:23AM -0500, Naushit Sakarvadia wrote:
> Hello All,
> 
> This is regarding PowerPC 8260 gdb.
> 
> My question is how do I tell gdb to read a byte only  while reading
> 0xfff00100..0xfff00500 address range.
> While  checking mem I uze  "x /b  0xfff00100" and it works fine , but while
> I do unassamble from this address it tries to read a word from this
> location, and as a result the first byte is repeated 4 times.It is 8 bit
> wide flash mem,so
> you cant read a word at a time.
> 
> So I want to tell gdb to do byte wide reading while doing unassambling and
> all other operations.
> 
> Please reply me personally, I am not on gdb mailing list.

This is a probablem with your remote stub, not GDB itself.  You'll have
to teach the stub to only do byte reads.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: 8 bit read

[Andrew Cagney]

> Hello All,
> 
> This is regarding PowerPC 8260 gdb.
> 
> My question is how do I tell gdb to read a byte only  while reading
> 0xfff00100..0xfff00500 address range.
> While  checking mem I uze  "x /b  0xfff00100" and it works fine , but while
> I do unassamble from this address it tries to read a word from this
> location, and as a result the first byte is repeated 4 times.It is 8 bit
> wide flash mem,so
> you cant read a word at a time.
> 
> So I want to tell gdb to do byte wide reading while doing unassambling and
> all other operations.
> 
> Please reply me personally, I am not on gdb mailing list.


FYI, J.T.C. was working on infrastructure to teach GDB about memory 
attributes.  A basic framework is in place only nothing uses it.
I believe his next step was to extend the protocol so that memory 
packets could include things like the read size.

	Andrew

Re: 8 bit read

[Eli Zaretskii]

On Mon, 23 Jul 2001, Andrew Cagney wrote:

> FYI, J.T.C. was working on infrastructure to teach GDB about memory 
> attributes.  A basic framework is in place only nothing uses it.
> I believe his next step was to extend the protocol so that memory 
> packets could include things like the read size.

I think we also need some programmatic interface to define memory
attributes.  Right now, the only way to do that is with an interactive
command, because the rest of the interface is private to memattr.c.

I was thinking about using memory attributes to allow GDB access to
segments outside the normal address space of the program being
debugged.  This would need some additions to the memory attributes,
but the real show-stopper is that there's no way to define regions and
attributes except interactively.

Re: 8 bit read

[Kevin Buettner]

On Jul 24,  2:50pm, Eli Zaretskii wrote:

> On Mon, 23 Jul 2001, Andrew Cagney wrote:
> 
> > FYI, J.T.C. was working on infrastructure to teach GDB about memory 
> > attributes.  A basic framework is in place only nothing uses it.
> > I believe his next step was to extend the protocol so that memory 
> > packets could include things like the read size.
> 
> I think we also need some programmatic interface to define memory
> attributes.  Right now, the only way to do that is with an interactive
> command, because the rest of the interface is private to memattr.c.
> 
> I was thinking about using memory attributes to allow GDB access to
> segments outside the normal address space of the program being
> debugged.  This would need some additions to the memory attributes,
> but the real show-stopper is that there's no way to define regions and
> attributes except interactively.

Why is this a show stopper?  A sequence of commands which define
attributes for different memory ranges can be placed in a file and
then sourced...

Kevin

Re: 8 bit read

[Eli Zaretskii]

> Date: Tue, 24 Jul 2001 09:25:31 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
> > 
> > I was thinking about using memory attributes to allow GDB access to
> > segments outside the normal address space of the program being
> > debugged.  This would need some additions to the memory attributes,
> > but the real show-stopper is that there's no way to define regions and
> > attributes except interactively.
> 
> Why is this a show stopper?

Because the implementation I had in mind was of a special interactive
command that would accept a selector for a memory region, define a
region, and stick the selector as a special attribute there.  The
target-specific memory-transfer function will then see that attribute
when GDB calls the to_xfer_memory method, and use special functions to
access that memory.

But the current API in memattr.c doesn't allow GDB applications code
to create memory regions except via the "mem" commands.

> A sequence of commands which define
> attributes for different memory ranges can be placed in a file and
> then sourced...

I don't see a smiley to go with the joke ;-)

Re: 8 bit read

[Kevin Buettner]

On Jul 24,  9:07pm, Eli Zaretskii wrote:

> > Date: Tue, 24 Jul 2001 09:25:31 -0700
> > From: Kevin Buettner <kevinb@cygnus.com>
> > > 
> > > I was thinking about using memory attributes to allow GDB access to
> > > segments outside the normal address space of the program being
> > > debugged.  This would need some additions to the memory attributes,
> > > but the real show-stopper is that there's no way to define regions and
> > > attributes except interactively.
> > 
> > Why is this a show stopper?
> 
> Because the implementation I had in mind was of a special interactive
> command that would accept a selector for a memory region, define a
> region, and stick the selector as a special attribute there.  The
> target-specific memory-transfer function will then see that attribute
> when GDB calls the to_xfer_memory method, and use special functions to
> access that memory.
> 
> 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 don't understand what you're trying
to do...

Kevin

Re: 8 bit read

[Eli Zaretskii]

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?

Re: 8 bit read

[Kevin Buettner]

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

Re: 8 bit read

[Eli Zaretskii]

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

Re: 8 bit read

[Andrew Cagney]

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


What Kevin is suggesting here is, from GDB's point of view, the correct 
approach.  A CORE_ADDR is a cannonical address - any pointer expression 
is converted to that cannonical value.  On the x86, it could carry an 
indication that the offset part belongs to either code, I/O, .. space.



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


That really means do a virtual->real address translation on all 
addresses as they head towards the target.  The d10v target managed 
this.  I'd view it as a proof of concept.


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


It is still an adventure GDB should take. It is like tiddles (TPID) - it 
is going to hurt :-)


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


The readers can at least do sign-extension.  The 32 bit MIPS makes use 
of this.


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


If I understand what you're saying correctly, you'd need a virtual 
(segment:offset) to physical translation somewhere down in the target code.

	Andrew

Re: 8 bit read

[Eli Zaretskii]

On Thu, 26 Jul 2001, Andrew Cagney wrote:

> > 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.
> 
> What Kevin is suggesting here is, from GDB's point of view, the correct 
> approach.  A CORE_ADDR is a cannonical address - any pointer expression 
> is converted to that cannonical value.  On the x86, it could carry an 
> indication that the offset part belongs to either code, I/O, .. space.

The problem is, I don't have enough bits in CORE_ADDR to include those 
indications.

> > It means to use a non-default segment selector to read and write
> > memory.
> 
> That really means do a virtual->real address translation on all 
> addresses as they head towards the target.

No, it means converting an offset relative to segment's base to a linear
address.  I don't need to map to a physical address in this case, that's 
something that is done transparently by the CPU, given the page tables 
that are set by the OS.

> The d10v target managed this.  I'd view it as a proof of concept.

If that was done by encoding all the info into CORE_ADDR, I cannot take 
this path, because CORE_ADDR is 32 bits and addresses are also 32 bits.

> If I understand what you're saying correctly, you'd need a virtual 
> (segment:offset) to physical translation somewhere down in the target code.

No, my problem is not a translation--that can be handled by the target 
code.  The problem is how to pass that information to the target code, 
given that it can only be either in the address itself or in the memory 
attributes which go with that address.

Re: 8 bit read

[Andrew Cagney]

>  What Kevin is suggesting here is, from GDB's point of view, the correct 
>> approach.  A CORE_ADDR is a cannonical address - any pointer expression 
>> is converted to that cannonical value.  On the x86, it could carry an 
>> indication that the offset part belongs to either code, I/O, .. space.
> 
> 
> The problem is, I don't have enough bits in CORE_ADDR to include those 
> indications.


Just FYI, you should find that CORE_ADDR type is already 64 bits.

	Andrew

Re: 8 bit read

[Eli Zaretskii]

On Thu, 26 Jul 2001, Andrew Cagney wrote:

> Just FYI, you should find that CORE_ADDR type is already 64 bits.

Not in the DJGPP version, not according to "ptype", anyway.

AFAICS, CORE_ADDR is the same type as bfd_vma, since defs.h has this:

   typedef bfd_vma CORE_ADDR;

How can you be sure that all targets define bfd_vma as a 64-bit data 
type?  Or am I missing something?

Re: 8 bit read

[Andrew Cagney]

> That really means do a virtual->real address translation on all 
>> addresses as they head towards the target.
> 
> 
> No, it means converting an offset relative to segment's base to a linear
> address.  I don't need to map to a physical address in this case, that's 
> something that is done transparently by the CPU, given the page tables 
> that are set by the OS.


FYI, by virtual->real I mean any sort of address translation, not just 
VM/pages.  The d10v's memory-management system is strictly base/bound 
(and a little strange at that :-).

	Andrew

Re: 8 bit read

[Andrew Cagney]

>> Just FYI, you should find that CORE_ADDR type is already 64 bits.
> 
> 
> Not in the DJGPP version, not according to "ptype", anyway.
> 
> AFAICS, CORE_ADDR is the same type as bfd_vma, since defs.h has this:
> 
>    typedef bfd_vma CORE_ADDR;
> 
> How can you be sure that all targets define bfd_vma as a 64-bit data 
> type?  Or am I missing something?


Sorry, no I'm wrong.  It is LONGEST that always ends up being 64 bits.

	Andrew

Re: 8 bit read

[Kevin Buettner]

On Jul 26,  4:45pm, Eli Zaretskii wrote:

> On Thu, 26 Jul 2001, Andrew Cagney wrote:
> 
> > > 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.
> > 
> > What Kevin is suggesting here is, from GDB's point of view, the correct 
> > approach.  A CORE_ADDR is a cannonical address - any pointer expression 
> > is converted to that cannonical value.  On the x86, it could carry an 
> > indication that the offset part belongs to either code, I/O, .. space.
> 
> The problem is, I don't have enough bits in CORE_ADDR to include those 
> indications.

I think if you review the mailing list archives, you'll find that more
than one person has suggested turning CORE_ADDR into a struct.  What
would such a struct look like?  Maybe something like this:

    struct core_addr
      {
        bfd_vma addr;		/* what we have now...  */
	int addr_space;		/* address space selector */
				/* maybe this should be an enum?  */
      };
    typedef struct core_addr CORE_ADDR;

(I'm sure we can think of better names for the members, but you get
the idea.)

I we take such a step, there'll be a fair chunk of code which won't
really notice the difference.  Such code performs no real manipulation
of a CORE_ADDR, it either stashes the value away and/or passes it on
to somewhere else.

The code that's going to be affected is that in which a constant is
added to or subtracted from a CORE_ADDR.  (There's some masking that
goes on too sometimes.)  For these, we'll need a constructor.  I.e,
something like the following...

    CORE_ADDR pc = read_pc ();
    ...
    pc = pc + 4;		/* Advance pc to next instruction.  */
    
might become...

    CORE_ADDR pc = read_pc ();
    ...
    pc = core_addr_add_int (pc, 4);
				/* Advance pc to next instruction.  */

where core_addr_add_int() has the obvious definition...

    CORE_ADDR
    core_addr_add_int (CORE_ADDR addr, int offset)
    {
      CORE_ADDR retval;

      retval.addr_space = addr.addr_space;
      retval.addr = addr.addr + offset;

      return retval;
    }

The nice thing about all of this is that a core_addr_add_core_addr()
could be made to internal_error() when attempting to add incompatible
addresses.  (As it is, our Harvard architecture implementations won't
care if you try to add a data address to a code address.  Doing so
probably represents a programming error though.)

Kevin

Re: 8 bit read

[Eli Zaretskii]

On Thu, 26 Jul 2001, Kevin Buettner wrote:

> I think if you review the mailing list archives, you'll find that more
> than one person has suggested turning CORE_ADDR into a struct.

Yes, I remember.

> What would such a struct look like?  Maybe something like this:
> 
>     struct core_addr
>       {
>         bfd_vma addr;		/* what we have now...  */
> 	int addr_space;		/* address space selector */
> 				/* maybe this should be an enum?  */
>       };
>     typedef struct core_addr CORE_ADDR;

If I see any practical plans to switch to such a representation, I'd sure 
hold my breath ;-)