From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: Kevin Buettner Cc: Naushit_Sakarvadia@quintum.com, gdb@sources.redhat.com Subject: Re: 8 bit read Date: Wed, 25 Jul 2001 23:39:00 -0000 Message-id: References: <1010725184015.ZM22683@ocotillo.lan> X-SW-Source: 2001-07/msg00367.html 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).