Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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 --]

  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