From owner-svn-src-head@FreeBSD.ORG Sun Aug 7 11:52:58 2011 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE9D106566B; Sun, 7 Aug 2011 11:52:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 42F288FC14; Sun, 7 Aug 2011 11:52:57 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p77BquK9043998; Sun, 7 Aug 2011 13:52:57 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p77Bquwt043997; Sun, 7 Aug 2011 13:52:56 +0200 (CEST) (envelope-from marius) Date: Sun, 7 Aug 2011 13:52:56 +0200 From: Marius Strobl To: Marcel Moolenaar Message-ID: <20110807115256.GG48988@alchemy.franken.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96C6C36B-E521-4438-9AEF-59D9A922D3B4@xcllnt.net> User-Agent: Mutt/1.4.2.3i Cc: src-committers@FreeBSD.org, Ruslan Mahmatkhanov , Garrett Cooper , svn-src-all@FreeBSD.org, Andriy Gapon , svn-src-head@FreeBSD.org Subject: Re: svn commit: r224683 - head/lib/libthread_db X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 11:52:58 -0000 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