<olerem>
heh, I do not have stron opition about this patch right now, I just do not like commit messages describe what patch is changing without telling why it is needed
<olerem>
lol.. s/stron opition/strong opinion
<olerem>
karlp: if you wont to have this patch, can you please update it. Add comment to the commit or may be to the code, why different value is needed
akaWolf has quit [Ping timeout: 268 seconds]
<karlp>
alright. well, obviously, it's a very short term patch to just increase the number.
<karlp>
what would people's opions be on offering a new command that lets you do profile server start, similar to rtt or tpiu server streaming?
<karlp>
so we can just stream out the pc samples?
<olerem>
karlp: i'm not deep enough in that topic. Can you please tell more
<olerem>
how do streaming of pc samples would work? By using non-jtag trace interface?
defiant has joined #openocd
jancoow has joined #openocd
<karlp>
no, I mean, instead of having openocd block for N seconds, then write a gprof file,
<karlp>
I'm proposing adding an alternative that would simply serve up the pc samples as a stream on a tcp port.
<olerem>
sounds good
defiant has quit [Quit: defiant]
<zapb__>
karlp, +1
slobodan has joined #openocd
<karlp>
I guess theres' 32 vs 64bit pc too...
<karlp>
is there likely a need for taht to be formatted at all? (like, with cpu or something?) or would it be safe to just blast out PC values?
<karlp>
I'm kinda leaning towards "you get a 'native' stream, not any sort of 'standard' stream"
<zapb__>
I would just dump PC values, 32 or 64 depending on the target
<zapb__>
It is up to the user to decode the stream (32 vs 64 bit) values
<olerem>
zapb__: it will probably make receiver implementation kind of tricky if there is no additional data
<zapb__>
olerem, yes, but you could get the information from Tcl RCP for example?
<zapb__>
Well, you could also send some metadata on every first connect
<karlp>
32/64 should be pretty easy to determine heuristically as well, from the data. multiple cores, perhaps not.
<zapb__>
you have a separate stream for each core, right?
<zapb__>
Maybe something like [number of bytes per sample] (once) [pc sample data]
<zapb__>
We have also targets that have PC < 32, right? STM8?
<zapb__>
Don't forget big and little endianess :D
<karlp>
nope, "native" format :)
<karlp>
I don't know if you'd ahve a separate stream for each core.
<zapb__>
Then you need to indicate the core somehow?
<zapb__>
Yes, obviously your solution needs some more parameters and should be multi-core compatible :D
<zapb__>
[target] profile start <seconds> <filename/ip:port> [start end] or something like that
<zapb__>
+ some stop command
<zapb__>
Maybe you want unlimited streaming as well
<zapb__>
(never used this kind of profiling)
<karlp>
I basically want to feed it to things like orbtop.
<karlp>
currently I have been turning on pc sampling into ITM stream, and trace picks it up, and I just turn the sampling on or off.
<karlp>
this needs to be actively polled, so somewhat different, but I'd _like_ to be able to use the same tooling.
<karlp>
(I'd _really_ like to just never work with cortex-m0+, but that's out o fmy hands)
<zapb__>
And orbtop expects raw PC samples?
<karlp>
well, classically it expects the ITM stream, and it picks PC samples out of them, but that's something I can work on separately...
<zapb__>
What I want to prevent is that we extend this profiling feature "somehow" and end up with a solution that is hard to extend later on (e.g. multi-core support)
<zapb__>
We have this problem at the moment with RTT unfortunately