Re: gprof store and reset pins
Nikola Valerjev <[email protected]>
| Newsgroups | gmane.comp.emulators.sid.devel |
|---|---|
| Message-ID | <[email protected]> |
Thanks a lot for the tips. I ended up doing the 'monitor' commands - i.e. monitor set gprof reset 1 monitor set gprof store 1 (actually since I'm directly writing through the socket to the gdb component, I ended up passing a "qRcmd,<hex-coded-command>" string). - Nikola Valerjev On Sat, 18 Oct 2003, Frank Ch. Eigler wrote: > Hi - > > > On Fri, Oct 17, 2003 at 12:41:14PM -0700, Nikola Valerjev wrote: > > [...] > > I've been trying to use gdb and gprof components in 'sid' to get the profiling > > information out. [...] > > I'm glad to hear it! > > > What I would like to do is get gmon.out dumped while still being connected. > > Also I would like to have some way of reseting the gprof info (driving the > > 'reset' pin) on demand [...] > > Since both these signals are carried over generic sid pins, any mechanism > at all that can result in pin events at times of your pleasure will work. > Among them: > - time-based scheduler events (host or target) > - hard-wired connection between the "save" and "reset" pins, probably > through a hw-glue-sequence; hmm, finding a way of automatically changing > the profiling data file name might be nice > - socket or console input > - memory-mapped I/O (mapping hw-glue-probe-bus components into memory, > connecting one of its output lines to the pin of your choice) > - using the gdb "monitor set COMPONENT ATTRIBUTE VALUE" command to > pass the "set ..." configuration line to cfgroot, thence to COMPONENT. > Consider COMPONENT=gprof, ATTRIBUTE=reset or save, VALUE=1, recalling > that most pins may be alternately driven using attribute-related calls. > - using the gprof component's own pc-limit-range attributes to automatically > limit its focus to a certain span of PC values. > > > - FChE >