This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [Patch] Another small memattr fix.
- From: Don Howard <dhoward at redhat dot com>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: <gdb-patches at sources dot redhat dot com>
- Date: Fri, 14 Jun 2002 12:44:43 -0700 (PDT)
- Subject: 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