This is the mail archive of the gdb-patches@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]
Other format: [Raw text]

Re: [Patch] Another small memattr fix.


On Fri, 14 Jun 2002, Kevin Buettner wrote:

> Don,
> 
> Could you explain this change in more detail?
> 
> > -  if (lo >= hi)
> > +  if (lo > hi-1)
> 
> I.e, with the exception of the boundary conditions (max int, min int),
> aren't these two equivalent when lo and hi are integers?
> 

Yes they are equivalent -- I was trying to address the boundary
conditions.  (Obviously this approch is wrong, wrong, wrong)

Memory regions are specified with an inclusive lower bound and an
exclusive upper bound, so

mem 0 4 wo 
mem 4 8 ro

means that addresses 0x0, 0x1, 0x2, 0x3 are writable and 0x4, 0x5, 0x6 0x7
are readable.  

The exclusive upper bound causes trouble when trying to address max int, 
as it wraps :

(Assuming 32 bit addresses)

mem 0xfffffff0 0x100000000 ==> 0xfffffff0 0x0  /* woops */



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

Another possiblity is that the interface could be changed, making the
upper bound inclusive also. 

Any preferences?




-- 
dhoward@redhat.com
gdb engineering








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