From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2882 invoked by alias); 7 Feb 2011 06:10:51 -0000 Received: (qmail 2867 invoked by uid 22791); 7 Feb 2011 06:10:50 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Feb 2011 06:10:44 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 3EB971B400C; Mon, 7 Feb 2011 06:10:43 +0000 (UTC) From: Mike Frysinger To: gdb-patches@sourceware.org Subject: Re: [PATCH] sim: change to 64bit time keeping to avoid 32bit overflows Date: Mon, 07 Feb 2011 06:10:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.37; KDE/4.5.5; x86_64; ; ) Cc: toolchain-devel@blackfin.uclinux.org References: <1271762168-12466-1-git-send-email-vapier@gentoo.org> <1293834266-16757-1-git-send-email-vapier@gentoo.org> In-Reply-To: <1293834266-16757-1-git-send-email-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1815479.fvkr9xIJKv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201102070110.40056.vapier@gentoo.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00121.txt.bz2 --nextPart1815479.fvkr9xIJKv Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 2085 On Friday, December 31, 2010 17:24:26 Mike Frysinger wrote: > The sim-events code jumps through some hoops to avoid using 64bit math > to manage the current time. One fundamental assumption here is that by > constantly scheduling the sim poll event a short time into the future, > the 64bit difference will always fall into a signed 32bit value. This > does work most of the time, except for when processing the sim poll event > itself. >=20 > Normally, sim_events_process() will dequeue the sim poll event, update > the current time (time_from_event) according to the next pending event, > process the sim poll event (which will then requeue the sim poll event), > and then continue on. >=20 > The problem here of course is that the current time is updated in that > small window before the sim poll event gets a chance to reschedule itself. > So if the 64bit difference between the current time and the next event > does not fit into the signed 32bit value, time_from_event overflows, and > the internal assert at the end of update_time_from_event() triggers. >=20 > Since attempts at tweaking sim_events_process() logic introduced other > subtle bugs (due to tangled assumptions between most pieces of the sim > time keeping code), change the time_from_event to a real 64bit value. > Tests on my system between a 32bit ELF and a 64bit ELF show no practical > difference (it's all lost in the system noise). Basically, I booted a > Linux kernel to userspace and then paniced it; this gave me a constant > sample size of about 18 million insns. >=20 > This was noticed when simulating Blackfin Das U-Boot. The simulated core > timer is given the max unsigned timeout value possible on a 32bit process= or > (0xffffffff). This timeout value is used directly to schedule a hw event > in the sim future (the IRQ firing). Once the sim poll event is kicked of= f, > the next pending event is the core timer event which is more than 2^31 > ticks in the future, and the sim aborts with: > sim-events.c:435: assertion failed - current_time =3D=3D sim_events_time = (sd) ping ... -mike --nextPart1815479.fvkr9xIJKv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJNT4zgAAoJEEFjO5/oN/WB/68QAJSOO4dzvipI5jQoI4WVJKTU lI4tSuObPa1BbtWdZnrYNBkVkkHkazXNS/mPyH8O9CDiwdM0Nj5bW2M09e+EoPp4 CVQgZB0zQlNc6GrVKN0nJ5GmM4I1kE0eP+4DndPyfc6yCbBTdCeTczNR5adFKAw/ kWFgF6ronZjEJpc2XctiZgKzwuGW3607B491pRdAFJoJFx7OJ8I6YI6/lsXDdN/c JVa/9re6Cm+eHrENRaJj72s7iiVEigGT1onDpAgBJddMgwpqj/16TZ+HbHyPodWo SLd18UjHfu7Imh7JKnXziIkuhlFIFu+wO/V4QUE3zBEviHCdA0X3v1z9RZ1vf+zk mios6sB1u/T8Goz1mVljLjLs0/tfE1DTVSVSaeLCQQTwHyt54FlvTrZtzYz9ghE/ uEAIoUsA704MfLRI/CLukDbRu9xwcNR3SofzqwE2HDHWxsqzDrAYeBbz035OuRqP 3LenGtcC8f/M+L5qbpmMrIfQ2agJl+Xjf0oZc/nuG9Z9VdmM++wc9OS/3su9p4v0 IwyBwUvEnKRfpIw6KxMfrMsppZyDzBhsD6qkO/Xb9J1WfYW18rqWUC7GHPTvT4W6 b3vT53pv2qeCmHpLnQnaQdTtYDgpxMzNwkt/3IaUMHXvQ2rZtlZOZEsbAKLRajtW w6JwbNLxisl0eNsDgsbL =Cg3X -----END PGP SIGNATURE----- --nextPart1815479.fvkr9xIJKv--