Re: getting gdb's "frame" command to be quiet? + convenience hashtables?

[Andrew Cagney <ac131313 at cygnus dot com>]

Hello,

Given the first looks like a bug (the doco is always right :-) and the 
second a good idea, yes, would you be able to create bug reports for this?

See http://sources.redhat.com/gdb/bugs/

Hmm, you may also be interested in the current sources.  At the bottom 
of the file std-regs.c is the code snipit:

  /* NOTE: cagney/2002-04-05: For moment leave the $frame / $gdbframe
     / $gdb.frame disabled.  It isn't yet clear which of the many
     options is the best.  */
  if (0)
    add_builtin_reg ("frame", value_of_builtin_frame_reg);

If you enable this, you get a variable ``$frame.base'' that you can use 
as part of identifying frames.  If you're wondering, the comment still 
applies - it might get changed to ``$frame.id''.

thanks for the problem reports,
Andrew




> Dear gdb maintainers:
>
> Please let me know whether I should file the bug report and/or enhancement 
> request indicated below.  Citations to GDB source locations from which I 
> might be able to derive candidate patches would be very welcome, too.
>
> I am using gdb to trace calls to malloc and calloc in a program where
> over 100,000 calls are made to those functions.  I wish to use breakpoints 
> on those functions to log stack backtraces that are different than the 
> previous stack backtraces.  
> Presently, I have tried this, which contrary to gdb documentation:
>
> define remember_malloc_pcs
>   frame 1                            # caller -- THIS SHOULDN'T PRINT!!!
>   set $m_f1_pc = $pc                 # $m_... for malloc, $c_... for calloc
>   frame 2                            # caller's caller
>   set $m_f2_pc = $pc                 # remember program counters
> end                                  # frame 3 omitted for brevity...
>
> break malloc
> commands
>   silent                             # I wish!
>   remember_malloc_pcs                # user-defined (above) --- NOT SILENT
>   frame 2                            # caller's caller
>   set $m_f2_pc = $pc                 # remember program counters
>   # frame 3 omitted for brevity...
>   if ($prev_m_f1_pc == $m_f1_pc && $prev_m_f2_pc == $m_f2_pc) 
>     continue  # this was the backtrace previously printed so don't be redundant
>     end
>   backtrace                          # print for the trace log
>   set $prev_m_f1_pc = $m_f1_pc       # remember to initalize all of these...
>   set $prev_m_f2_pc = $m_f1_pc       #... $prev_ vars before first breakpoint
>   continue                           # resume program execution
> end
>
> Question 1:  How can I cause "frame" to be quiet and not print?  The 
> documentation ("help frame") *suggests* it will not print when used 
> from a user-defined function, but that is not the case.  I.e.:
>
>    (gdb) help frame
>    Select and print a stack frame.
>    With no argument, print the selected stack frame.  (See also "info frame").
>    An argument specifies the frame to select.
>    It can be a stack frame number or the address of the frame.
>    With argument, nothing is printed if input is coming from
>    a command file or a user-defined command.
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^
> I have tried using the commands above in a user-defined subroutine, and it 
> does not keep output from being printed.
>
>   (BUG REPORT:  INCORRECT DOCUMENTATION ON "frame")
>
> Question 2:  [How] can I use a hash table of strings (like an AWK 
> associative array, e.g.) to store the names of the functions in the 
> stack frames for later comparison to see if they have been seen before?
>
>   (POTENTIAL ENHANCEMENT REQUEST:  ADD CONVENIENCE HASH TABLES)
>
> Thank you all for your kind volunteerism and help on these questions 
> if at all possible.