|Re: [hatari-devel] symbols not always loaded when entering debugger ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 11/18/2017 11:15 PM, David Savinkoff wrote:
Hatari has so many options that higher level options are needed.
These higher level options should be default 'user friendly' RTFM_not
(see ffmpeg as an example).
Do you have suggestions on what kind of higher level options would
be most useful?
I don't know what a call-graph is, and
that part of the manual scares me.
Call-graphs generated by the hatari_profile tool show how everything
in a program that has a symbol for itself (functions, subroutines etc),
calls other such things, and how many times. They also show how much
each of them costs in isolation, and in total. Costs for them are shown
as number of:
- cache hits/misses
(A separate graph is generated for each of these.)
If you haven't written all of the profiled code yourself, profile gives
you faster an overview of how it all works together in reality, in given
situation, than reading the code. It's even better if you don't have
source for a binary, but it does contain symbols...
(On Linux, one would use valgrind & kcachegrind to get similar data.)
All of these kind of tools I've used, have some details about how they
collect the data that user may need to know to interpret the data
correctly (you will encounter them at some point when using the tools
That's why that part of the manual is so large. To get everything out
of a profiler, one needs to know something about how it works, not
just how to use it.
----- On Nov 17, 2017, at 3:47 PM, Eero Tamminen wrote:
(Debugging use-cases are different from non-debugging
use-cases and debugging settings can have downsides for
normal emulator usage. While not as drastic, automatic
symbol loading for terminating programs can also have
downsides, at least it generates extra output to console.)
I commited a change which skips most of the warnings
for "symbols resident" mode. For larger GCC/MiNTLib
programs they could be several screenfuls.