From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27422 invoked by alias); 20 Apr 2010 11:16:06 -0000 Received: (qmail 27413 invoked by uid 22791); 20 Apr 2010 11:16:05 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=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; Tue, 20 Apr 2010 11:15:59 +0000 Received: from localhost.localdomain (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id CE90F1B40B4 for ; Tue, 20 Apr 2010 11:15:56 +0000 (UTC) From: Mike Frysinger To: gdb-patches@sourceware.org Subject: [PATCH] sim: fix signed 32bit time overflow with long delayed events Date: Tue, 20 Apr 2010 11:16:00 -0000 Message-Id: <1271762168-12466-1-git-send-email-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: 2010-04/txt/msg00609.txt.bz2 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. 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. 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. This was noticed when simulating Blackfin Das U-Boot. The simulated core timer is given the max unsigned timeout value possible on a 32bit processor (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 off, 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 == sim_events_time (sd) Signed-off-by: Mike Frysinger --- 2010-04-20 Mike Frysinger * sim-events.c (sim_events_process): Delay update_time_from_event() till after the call to handler(). sim/common/sim-events.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/sim/common/sim-events.c b/sim/common/sim-events.c index e02fb76..3fa5433 100644 --- a/sim/common/sim-events.c +++ b/sim/common/sim-events.c @@ -1172,7 +1172,6 @@ sim_events_process (SIM_DESC sd) sim_event_handler *handler = to_do->handler; void *data = to_do->data; events->queue = to_do->next; - update_time_from_event (sd); ETRACE((_ETRACE, "event issued at %ld - tag 0x%lx - handler 0x%lx, data 0x%lx%s%s\n", (long) event_time, @@ -1183,6 +1182,10 @@ sim_events_process (SIM_DESC sd) (to_do->trace != NULL) ? to_do->trace : "")); sim_events_free (sd, to_do); handler (sd, data); + /* Update time *after* the handler in case it inserted an event itself. + Like in the case of the persistent sim poll event. Otherwise, our + 32bit math assumption may be violated and overflow. */ + update_time_from_event (sd); } /* put things back where they belong ready for the next iteration */ -- 1.7.0.2