On Sun, Aug 07, 2011 at 12:22:02PM +0000, Bjoern A. Zeeb wrote: > > On Aug 7, 2011, at 11:52 AM, Marius Strobl wrote: > > > 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? > > Given this, can you please back it out, find a proper solution together, test > it and re-add that then? >
I'm currently running a universe build with lwp changed from long to int64_t. This should compile and work on all architectures for native-debugging and as such be a step in the right direction. In a second step thr_p{read,write}_{long,ptr}() then can be fixed to also do the right thing when cross-debugging. Marius _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"