|Re: [hatari-devel] Allocation etc tracking (was BM407 + symbols)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On sunnuntai 07 huhtikuu 2013, Douglas Little wrote:
> > If you need some kind of system side memory allocation statistics,
> > I could look into adding something for that. With profiler caller
> > tracking it might even be possible to get JSR/BSR call backtraces
> > for those (or more generally, to specified GEMDOS functions).
> That might be quite useful, although the best way to do this is normally
> through some sort of API (so you can associate allocations with
I've done a lot of resource usage analysis at work, and with right tools,
you need manually added context information only for tracking server
allocations, to see for which of its clients they belong to.
When stuff happens in single process (i.e. you don't need to track which
external actor triggered the resource allocation), I've found good
backtraces (and callgraphs done out of them) usually to be enough.
If you for some reason don't have working backtraces, then separate
context information is also useful.
From which we come to the fact that Hatari profiler can now provide
information needed to output backtraces for subroutine calls...
I could for example add an option to breakpoints that will dump out
"stack" backtrace every time such breakpoint is triggered. And this
would work for any breakpoint, not just TOS allocation calls.
So, if one would want to do allocation tracing, it should be enough
to set such a breakpoint for GEMDOS allocation function(s), and
trace GEMDOS calls. GEMDOS trace would output some extra info,
but on can grep them out. :-)
The nice thing about this is that wouldn't be limited to allocation
tracking, you could track *anything*. Set for example such a breakpoint
to your own program's functions, to get backtraces to their calls.
If those functions will output their arguments (e.g. to --counout
console or NatFeats StdErr API), you would have pretty powerful extra