This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] sim: change to 64bit time keeping to avoid 32bit overflows


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: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]