This is the mail archive of the
mailing list for the GDB project.
Re: RFA: Do solib address arithmetic with appropriate truncation
Kevin Buettner <email@example.com> writes:
> On Feb 2, 8:31pm, Jim Blandy wrote:
> > Sat Feb 2 17:03:26 2002 Jim Blandy <firstname.lastname@example.org>
> > * solib-svr4.c (svr4_truncate_ptr): New function.
> > (svr4_relocate_section_addresses): Do the address arithmetic with
> > the appropriate truncation for target addresses, even when
> > CORE_ADDR is larger than a target address.
> I think this is a satisfactory short term (or even mid term) solution.
> I think the long term solution will be to introduce a method for adding
> offsets to CORE_ADDRs. See
> I think it's okay to commit this patch, but I'd appreciate it if you'd
> add a comment indicating that svr4_truncate_ptr() should be removed
> when methods for adding displacements to CORE_ADDRs are introduced.
Okay, I've committed it with the following comment:
/* Clear any bits of ADDR that wouldn't fit in a target-format
data pointer. "Data pointer" here refers to whatever sort of
address the dynamic linker uses to manage its sections. At the
moment, we don't support shared libraries on any processors where
code and data pointers are different sizes.
This isn't really the right solution. What we really need here is
a way to do arithmetic on CORE_ADDR values that respects the
natural pointer/address correspondence. (For example, on the MIPS,
converting a 32-bit pointer to a 64-bit CORE_ADDR requires you to
sign-extend the value. There, simply truncating the bits above
TARGET_PTR_BIT, as we do below, is no good.) This should probably
be a new gdbarch method or something. */