[patch rfc] Eliminate extract_address
Andrew Cagney
ac131313@redhat.com
Thu May 15 16:49:00 GMT 2003
> Can you explain why you doing
>
> s/extract_address/extract_unsigned_integer/
>
> is a good thing?
> Perhaps this has been discussed already, but I see two drawbacks...
>
> First, the return types are different. extract_address() returns
> CORE_ADDR while extract_unsigned_integer returns ULONGEST. If
> we were to encounter a scenario where this is a problem, it's easier
> to fix a wrapper (extract_address()) instead of the myriad places in
> the code which presently call extract_address(). (This point is
> probably moot because I suspect we already have a lot of code which
> assumes that CORE_ADDR may be interchanged with LONGEST or ULONGEST
> anyway.)
sizeof(CORE_ADDR) <= sizeof(ULONGEST) so this isn't a problem.
> Second, having function calls to extract_address() provides
> information to the reader that you don't get by having calls to
> extract_unsigned_integer(). It tells the reader that we're expecting
> to get an address and not an integer. This really helps when someone
> reading gdb's code is wondering about what the thing is that's being
> extracted.
The extract_address function doesn't extract an address, it extracts an
unsigned integer.
On the MIPS, extract_address needs to sign extend. On the d10v, extract
address needs to know the address space.
If the code needs to extract an address it can use extract_typed_address
which corectly handles all these cases.
Is it a good thing? It eliminates a lie.
enjoy,
Andrew
More information about the Gdb-patches
mailing list