Date: Sun, 7 Aug 2011 12:22:02 +0000 From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r224683 - head/lib/libthread_db Message-ID: <6949F340-1B6F-4001-9E99-7D6AF2FD5B48@FreeBSD.org> In-Reply-To: <20110807115256.GG48988@alchemy.franken.de> References: <201108061748.p76HmUbM061259@svn.freebsd.org> <4E3DA560.6020100@yandex.ru> <CAGH67wSFRXLRBVcoR8RME111pE7UaZ%2By-k8qmTtCkOy%2BMC3Dhw@mail.gmail.com> <4E3DBAF8.5040102@FreeBSD.org> <20110806232415.GE48988@alchemy.franken.de> <96C6C36B-E521-4438-9AEF-59D9A922D3B4@xcllnt.net> <20110807115256.GG48988@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 7, 2011, at 11:52 AM, Marius Strobl wrote:
> On Sat, Aug 06, 2011 at 07:35:49PM -0700, Marcel Moolenaar wrote:
>>=20
>> On Aug 6, 2011, at 4:24 PM, Marius Strobl wrote:
>>=20
>>> 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).
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> Yes, the type of val is wrong. I'm currently running a fix through a
>>> universe build
>>=20
>> Ah, euh, ok, I forgot about this particular quirk:
>>=20
>> 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).
>>=20
>> That's why thr_pread_long() takes a pointer to uint64_t and
>> thr_pread_int() takes a pointer to uint32_t...
>>=20
>> Sorry for missing this in the review.
>=20
> 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?
Thanks
--=20
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6949F340-1B6F-4001-9E99-7D6AF2FD5B48>