From owner-svn-src-all@FreeBSD.ORG Sun Aug 7 12:22:07 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48A7C1065673; Sun, 7 Aug 2011 12:22:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id C97708FC19; Sun, 7 Aug 2011 12:22:06 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A356125D3888; Sun, 7 Aug 2011 12:22:05 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B6F16BD3C89; Sun, 7 Aug 2011 12:22:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id x3WCx-OeIQKj; Sun, 7 Aug 2011 12:22:03 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 28E96BD3C3F; Sun, 7 Aug 2011 12:22:03 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20110807115256.GG48988@alchemy.franken.de> Date: Sun, 7 Aug 2011 12:22:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6949F340-1B6F-4001-9E99-7D6AF2FD5B48@FreeBSD.org> References: <201108061748.p76HmUbM061259@svn.freebsd.org> <4E3DA560.6020100@yandex.ru> <4E3DBAF8.5040102@FreeBSD.org> <20110806232415.GE48988@alchemy.franken.de> <96C6C36B-E521-4438-9AEF-59D9A922D3B4@xcllnt.net> <20110807115256.GG48988@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r224683 - head/lib/libthread_db X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 12:22:07 -0000 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.=