From: Mike Frysinger <vapier@gentoo.org>
To: gdb-patches@sourceware.org
Cc: toolchain-devel@blackfin.uclinux.org
Subject: Re: [PATCH] sim: change to 64bit time keeping to avoid 32bit overflows
Date: Mon, 07 Feb 2011 06:10:00 -0000 [thread overview]
Message-ID: <201102070110.40056.vapier@gentoo.org> (raw)
In-Reply-To: <1293834266-16757-1-git-send-email-vapier@gentoo.org>
[-- Attachment #1: Type: Text/Plain, Size: 2104 bytes --]
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.
>
> 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.
>
> 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.
>
> 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)
ping ...
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2011-02-07 6:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-20 11:16 [PATCH] sim: fix signed 32bit time overflow with long delayed events Mike Frysinger
2010-04-23 2:30 ` Mike Frysinger
2010-12-31 23:01 ` [PATCH] sim: change to 64bit time keeping to avoid 32bit overflows Mike Frysinger
2011-02-07 6:10 ` Mike Frysinger [this message]
2011-02-14 4:09 ` Joel Brobecker
2011-02-14 5:15 ` Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201102070110.40056.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=gdb-patches@sourceware.org \
--cc=toolchain-devel@blackfin.uclinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox