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 01:45:00 -0000 Message-id: References: <1010724211116.ZM20834@ocotillo.lan> X-SW-Source: 2001-07/msg00358.html 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?