On 14/11/14 18:16, joaoandrefe...@sapo.pt wrote: > But if I measure the time on the host I will be including the serial > connection time, which isn't very accurate (unless I'm misinterpreting > your suggestion, of course!). What I'm currently doing is calling > "date +%s.%N" on the target's shell right before sending the "echo g > > /proc/sysrq-trigger" command, and right after sending "cont" from GDB. > This isn't a perfect approach because the commands are sent through > serial line, though.
Agreed. Why are you not using serial breaks to stop the target? That only involves a 2 byte packet on the UART and the target will handle it from interrupt context (meaning no scheduler jitter before the stop request is handled). > The perfect solution would involve getting the > time on the target, and my approach with the debugging messages was > with that in mind (measure the time starting when the "echo (...)" > packet arrives to the target and stopping when the GDB packet with > "cont" arrives to the target also. Regarding this, I think that the > more reasonable debug options to use are "set debug timestamp" + "set > debug remote", but I don't know if this "packet approach" is more > reasonable than a similar one (also using GDB debugging messages) but > concerning the execution of the internal KGDB functions (understanding > which are the first and last functions to be executed in this time > interval, and get the repective timestamps). It is a matter of > understanding which are the precise 2 "points" where execution stops > and resumes on the target, I guess. Serial ports are very slow compared to CPU. Thus I would not except the error introduced by careful timestamping on the host (i.e. where you figure out when the *last* character of a packet was transmitted) to be very significant since the cost to the target of the transaction is dominated by the time spent waiting for the UART. Thus unless the target system is under very heavy interrupt load the moment the 'g' character after the serial break is sent is close to the point the other CPUs will stop. Likewise the final ack issued by kgdb should be close to the point of restart. That said adding instrumentation on the target (kgdb_cpu_enter) is the only realistic way to measure the error introduced by measurement from the host. Daniel. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
