----- 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
