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] |
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] |