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: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Kevin Buettner <kevinb at redhat dot com>, <gdb-patches at sources dot redhat dot com>
- Date: Fri, 14 Jun 2002 14:19:04 -0700 (PDT)
- Subject: Re: [Patch] Another small memattr fix.
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