svn commit: r224683 - head/lib/libthread_db

Marius Strobl marius at alchemy.franken.de
Sun Aug 7 11:52:58 UTC 2011


On Sat, Aug 06, 2011 at 07:35:49PM -0700, Marcel Moolenaar wrote:
> 
> On Aug 6, 2011, at 4:24 PM, Marius Strobl wrote:
> 
> > On Sun, Aug 07, 2011 at 01:06:48AM +0300, Andriy Gapon wrote:
> >> on 07/08/2011 00:41 Garrett Cooper said the following:
> >>> It's not just i386. It's other architectures like arm, mips, and pc98
> >>> according to the tinderbox reports (this list is potentially
> >>> incomplete).
> >> 
> >> Yeah, confusingly enough thr_pread_long() is declared to take uint64_t* as its
> >> third argument, so this commit breaks all platforms where uint64_t is not
> >> derived from (unsigned) long.
> >> Just in case, thr_pread_int() takes uint32_t* as well.
> >> 
> > 
> > Yes, the type of val is wrong. I'm currently running a fix through a
> > universe build
> 
> Ah, euh, ok, I forgot about this particular quirk:
> 
> uint64_t is deliberate, because it's the width of long on 64-bit
> architectures and thread_db is to be used as a support library
> for a cross-tool (i.e. a 32-bit debugger for a 64-bit target).
> 
> That's why thr_pread_long() takes a pointer to uint64_t and
> thr_pread_int() takes a pointer to uint32_t...
> 
> Sorry for missing this in the review.

Okay, but then I don't know how to properly fix this given that
thr_p{read,write}_long() still seem to do the wrong thing as they
supply sizeof(long) rather than the size of a long on the target
to thr_p{read,write}() as the size of the value in the target
address space. If I change the callers of thr_pread_long() to
supply a uint64_t this will compile but it still does the wrong
thing in the cross-debugging case and I can't even think of how
to fix that without additional information about the target, i.e.
just using sizeof(uint64_t) obviously also is the wrong thing.
Both thr_p{read,write}_ptr() are similarly confusing as they take
a psaddr_t which is defined as uint64_t but use sizeof(void *)
which again is specific to the host rather tan the target.
Do you have a suggestion how to fix these?

Marius



More information about the svn-src-head mailing list