public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug symtab/13590] New: always display addresses in "info var" output
@ 2012-01-11 20:33 dje at google dot com
  2012-01-11 20:51 ` [Bug symtab/13590] " ppluzhnikov at google dot com
  2012-01-13 22:39 ` ppluzhnikov at google dot com
  0 siblings, 2 replies; 3+ messages in thread
From: dje at google dot com @ 2012-01-11 20:33 UTC (permalink / raw)
  To: gdb-prs

http://sourceware.org/bugzilla/show_bug.cgi?id=13590

             Bug #: 13590
           Summary: always display addresses in "info var" output
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
        AssignedTo: unassigned@sourceware.org
        ReportedBy: dje@google.com
    Classification: Unclassified


"info var foo" doesn't always display the variable's address.
IWBN if it did.

foo.c:

struct foo
{
  int x;
};

struct foo bar;

int
main ()
{
  return 0;
}

With debug info:

(gdb) info var bar
All variables matching regular expression "bar":

File 4902939.c:
struct foo bar;

Without debug info:

(gdb) info var bar
All variables matching regular expression "bar":

Non-debugging symbols:
0x00000000004019c8  bar

[I realize why it currently works this way.
The point is to print the address.]

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug symtab/13590] always display addresses in "info var" output
  2012-01-11 20:33 [Bug symtab/13590] New: always display addresses in "info var" output dje at google dot com
@ 2012-01-11 20:51 ` ppluzhnikov at google dot com
  2012-01-13 22:39 ` ppluzhnikov at google dot com
  1 sibling, 0 replies; 3+ messages in thread
From: ppluzhnikov at google dot com @ 2012-01-11 20:51 UTC (permalink / raw)
  To: gdb-prs

http://sourceware.org/bugzilla/show_bug.cgi?id=13590

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at google dot
                   |                            |com

--- Comment #1 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2012-01-11 20:51:39 UTC ---
I don't believe dje provided a sufficiently motivating example.

Consider:

foo.h
typedef struct foo { int x; } foo_t;

foo.c
#include "foo.h"

static foo_t foo;
...

bar.c
#include "foo.h"

static foo_t foo;
...

When the two files above are linked together, and "-g" is in effect, how can I
set a watchpoint on one or the other?

(gdb) info var foo
All variables matching regular expression "foo":

File foo.c:
static foo_t foo;

File bar.c:
static foo_t foo;

(gdb) p &foo
$2 = (foo_t *) 0x601028   <<< which one is this?

(gdb) p &foo.c::foo       <<< is there a syntax for that?
A syntax error in expression, near `::foo'.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug symtab/13590] always display addresses in "info var" output
  2012-01-11 20:33 [Bug symtab/13590] New: always display addresses in "info var" output dje at google dot com
  2012-01-11 20:51 ` [Bug symtab/13590] " ppluzhnikov at google dot com
@ 2012-01-13 22:39 ` ppluzhnikov at google dot com
  1 sibling, 0 replies; 3+ messages in thread
From: ppluzhnikov at google dot com @ 2012-01-13 22:39 UTC (permalink / raw)
  To: gdb-prs

http://sourceware.org/bugzilla/show_bug.cgi?id=13590

--- Comment #2 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2012-01-13 22:38:50 UTC ---
It gets even worse if some of the sources have debug info, while others don't.
In that case, the variable without debug info is completely hidden:

// foo.h
typedef struct foo { int x; } foo_t;

// foo.c
#include "foo.h"

static foo_t foo;

int foo_fn() { return foo.x++; }

// bar.c
#include "foo.h"

static foo_t foo;

int bar_fn() { return foo.x++; }

// main.c
int main()
{
  return foo_fn() + bar_fn();
}


1. Without debug info we get the *best* info:

gcc main.c foo.c bar.c
gdb -q a.out
Reading symbols from /tmp/gdb-bug/a.out...(no debugging symbols found)...done.
(gdb) info var foo
All variables matching regular expression "foo":

Non-debugging symbols:
0x0000000000601028  foo
0x000000000060102c  foo

2. With full debug info we get source location, but no address:

gcc main.c foo.c bar.c -g
gdb -q a.out
Reading symbols from /tmp/gdb-bug/a.out...done.
(gdb) info var foo
All variables matching regular expression "foo":

File foo.c:
static foo_t foo;

File bar.c:
static foo_t foo;


3. With partial debug info, one of the variables is completely *hidden*. This
is  very misleading. In my case, the variable in a.out didn't have debug info,
but a variable in shared library did. GDB printed the variable in shared
library, even though the variable in main executable was the one that was being
actually used.

gcc -c bar.c
gcc -g main.c foo.c bar.o
gdb -q a.out
Reading symbols from /tmp/gdb-bug/a.out...done.
(gdb) info var foo
All variables matching regular expression "foo":

File foo.c:
static foo_t foo;

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-01-13 22:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-11 20:33 [Bug symtab/13590] New: always display addresses in "info var" output dje at google dot com
2012-01-11 20:51 ` [Bug symtab/13590] " ppluzhnikov at google dot com
2012-01-13 22:39 ` ppluzhnikov at google dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).