Re: [Patch] Another small memattr fix.

[Don Howard <dhoward@redhat.com>]

On Fri, 14 Jun 2002, Andrew Cagney wrote:

> > On Jun 14, 12:44pm, Don Howard wrote:
> > 
> > 
> >> The strings are arbitrary expressions and are converted to address via
> >> parse_and_eval_address(), which does not flag overflow:
> >> 
> >> mem_command (char *args, int from_tty)
> >> {
> >>   CORE_ADDR lo, hi;
> >>   char *tok;
> >>   struct mem_attrib attrib;
> >> 
> >>   if (!args)
> >>     error_no_arg ("No mem");
> >> 
> >>   tok = strtok (args, " \t");
> >>   if (!tok)
> >>     error ("no lo address");
> >>   lo = parse_and_eval_address (tok);
> >> 
> >>   tok = strtok (NULL, " \t");
> >>   if (!tok)
> >>     error ("no hi address");
> >>   hi = parse_and_eval_address (tok);
> >> 
> >> mabe parse_and_eval_address could detect overflow and throw an error().
> 





> On real hardware, addresses overflow causes it to wrap.  The problem of 
> signed vs unsigned addresses is also lurking in there as well.
> 
>  From memory there is a tabled proposal to add a CORE_ADDR alu object so 
> that CORE_ADDR arrithmetic is correct.
> 
> > Maybe I'm missing something, but it seems to me that you're still left
> > with the problem of how to represent the maximum address + 1.  (Throwing
> > an error doesn't really help, does it?)
> > 
> > 
> >> Another possiblity is that the interface could be changed, making the
> >> upper bound inclusive also. 
> > 
> > 
> > This sounds better.
> > 
> > So, on a 16 bit machine, you could say
> > 
> >     mem 0xf000 0xffff ro
> > 
> > to indicate that the top 4096 bytes are read-only.
> 
> I can think of three alternatives:
> 
> 	[base, bound)
> 	[base, bound]
> 	[base, base+size-1)
> 
> The first one is what the doco says and has been there for a while so I 
> don't think that changing it is a good idea.
> 
> Internally, I suspect base+size-1 is the best representation.  However, 
> for the user interface, is there anything that really says that:
> 
> 	mem 0xfffffff0 0
>
> is either illegal or poorly defined?  


The fact that the first bound is inclusive and the second is exclusive
implies that to me. Also, the current implemntation enforces it.


How's this: let the parser find the size of the region for us:

labs (parse_and_evaluate_long (tok1 " - " tok2));


That seems to avoid the max int problem.  Then we can use base and size
as the internal representation.




-- 
dhoward@redhat.com
gdb engineering