On 14/11/14 02:51, joaoandrefe...@sapo.pt wrote: > Good evening, > > I've made a small bash script that performs a single bit-flip on a > target with KGDB. It tells it to stop, makes the bit-slip, and resumes > the target's execution. I need to estimate, as accurately as possible, > the impact / intrusion that this operation has on the target. In other > words, I need to estimate the amount of time in which the target's > normal execution is suspended, being it the execution of KGDB code, or > the period of time it is "frozen". So it would be the sum of X + Y ms, > am I thinking right?
I'm inclined to say, if you care about the time spent interrupted, then it would be better to find a different fault injection mechanism (the previously mentioned /dev/kmem is good for this). However it you really *have* to use kgdb then adding printk() calls to kgdb_cpu_enter() is an option (CONFIG_PRINTK_TIME). Alternatively simply measure elapsed time on the host (measure from when you send the serial break to when the restart packed is acked). Daniel. > > That said, I have three possible approaches on my head: > > 1 - The first one has to do with the time counter. When I send the > "echo g > /proc/sysrq-trigger" command through minicom, the target > freezes totally and it enters KGDB, as it is widely known. After > making the bit-flip on the target and resuming execution with the > "cont" command on GDB, the system clock is correctly updated, so there > must be a time counter somewhere that starts when the system freezes > and enters KGDB. I've been looking at the KGDB source code, but still > haven't found out where this counter exactly is. Does anyone know more > on this? > > 2 - Another possible solution would be using debugging messages, with > timestamps associated. This is still only an hypothesis, but I think > that after using the "set debug timestamp" option to turn on the > display of timestamps with GDB debugging info, in conjuction with some > additional commands to enable optional debugging messages (I'm > thinking of "set debug remote 1" for instance, since it shows the > packets going back and forth across the serial line to the target), > maybe it would be possible to know exactly when the system stopped > (and resumed). If I can identify which are the debugging messages that > mark the precise moment when the target stops (and resumes) execution, > than I only have to look at the seconds and microseconds associated to > that message, and do that simple subtraction. If this is a feasible > approach, it would be the preferred one, since it would be quicker to > reach, and wouldn't be necessary to change code. > > 3 - Finally, it is always possible to change code and get the target's > system time right before it's execution is stopped, and right after it > is resumed. After looking at the source code, I understand that the > function "kgdb_breakpoint()" is always called by the KGDB core and > acts as some kind of "reference" each time the debugger is launched. > However, I don't know if this is the first code run when entering > KGDB, i. e., if getting the system time inside this function would be > accurate for my needs. Do you know in which parts of the code can be > considered that the target started its "frozen state" (and on the > other hand, where in the code we can consider that the execution is > resumed)? So that my measurements are as accurate as possible. > > 4 - If you're thinking of other solutions, and / or it seems that some > of the three approaches I mentioned above doesn't make sense, I would > like to know your opinion on that. > > Best regards and thanks for reading, > João > > > > > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk > _______________________________________________ > Kgdb-bugreport mailing list > Kgdb-bugreport@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport > ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
