This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Print addresses of all local variables
- From: Doug Evans <dje at google dot com>
- To: Suryansh Kumar <suryansh dot 1234 at gmail dot com>
- Cc: gdb <gdb at sourceware dot org>, Vini Kanvar <vini at cse dot iitb dot ac dot in>
- Date: Tue, 23 Jun 2015 10:14:27 -0500
- Subject: Re: Print addresses of all local variables
- Authentication-results: sourceware.org; auth=none
- References: <CADA370v-0JBveYZ8WsEq2np914uWoU=dtL=XSBy6eFwYy6CsZg at mail dot gmail dot com>
On Wed, Jun 17, 2015 at 3:55 AM, Suryansh Kumar <suryansh.1234@gmail.com> wrote:
> Print addresses
> ----------------
> I want to print the addresses of all the local and global variables
> which are being used in the current frame and store them in a file.
> "info local" prints the values of all local variables. I need something
> to print the addresses in a similar way. Is there any built in
> command for it?
No, but one might be able to do something in python.
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
> GDB macro coding language tutorial
> -----------------------------------
> I tried writing a gdb script for the same using the gdb macro coding
> language, but I am not able to find sufficient material for it. Any
> handbook or tutorial on the gdb scripting language which covers its
> usage and syntax in detail is urgently needed. I need to know if we can
> declare arrays and strings, and perform comparisons on them.
gdb's own scripting language is really limited.
Use Python.
There's also Guile support, but the Python support is more complete.
https://sourceware.org/gdb/current/onlinedocs/gdb/Guile.html
> "step" into non-library functions
> ----------------------------------
> I need to store the data at the end of every function when it is
> executed using a gdb script. I am not able to use the 'step' command
> in the script as it also steps into the library functions, which I
> don't need. Need a way to run step conditionally on user functions
> only.
There's no real way to distinguish user from non-user functions.
There are ways to achieve what you want though.
1) The "skip" set of commands.
https://sourceware.org/gdb/current/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html
2) gdb won't step into functions that are missing debug info.
You *could*, though I'm not recommending this as a great approach,
remove the debug info for functions you don't want gdb to step into.
E.g., if you have debug info installed for glibc, temporarily remove it.