----- Original Message -----
Dave,
thank you for your comment. I've also reviewed the set of existing gdb
functions more carefully. Looks like it wasn't necessary to modify existing
code in gdb. It suffice to use another function from the same structure (it
hasn't been used before - that is why I hadn't noticed it earlier).
OK good.
I've also rewritten the logic within `whatis` command.
Yeah, actually the whatis command looks like a good fit for this functionality.
Another few changes I'd like you to make. If you notice, there are no calls
from the top-level crash sources directly into gdb functions, but rather they
all pass through gdb_interface(), which calls into gdb_command_funnel(). It's
always been done that way in order to keep the top-level crash running in case
of a fatal bug in the execution of gdb code. Can you please rework your code
to use gdb_interface()? It should be simple -- you'll just have to add a new
GNU command, and then have gdb_command_funnel() act upon it to call your new
function.
Secondly, the only time malloc() should ever be used is if an allocation is
permanent, so please don't use it in request_types(). Use GETBUF() instead,
which will be free up the memory after the command is run if you forget to
call FREEBUF(), or should the command fail prematurely.
For the same reason, it would be preferable if you can avoid the xmalloc() and
xrealloc() calls in the gdb code. Historically the gdb cleanup code has been
a source of problems when combined with the crash utility. Would it be possible
to use GETBUF() in request_types() to pre-allocate enough space for your gdb
function to accomplish its purpose?
Thanks,
Dave
Thanks,
Alexandr
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility