Re: symtab/1279: gdb doesn't lookup file/line information for global variables

[Jim Blandy <jimb at redhat dot com>]

The following reply was made to PR symtab/1279; it has been noted by GNATS.

From: Jim Blandy <jimb@redhat.com>
To: msimons@simons-clan.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: symtab/1279: gdb doesn't lookup file/line information for global variables
Date: 14 Jul 2003 15:48:25 -0500

 I've reproduced this bug using GCC 3.3 and today's GDB.  I think the
 problem is as follows:
 
 In GDB's data structures, 'struct symbol' records only the line number
 of the definition; there is no indication of which file the definition
 occurs in.  However, each 'struct symbol' occurs in the blockvector of
 a particular 'struct symtab'; each 'struct symtab' corresponds to a
 particular compilation unit, so GDB assumes that the variable's
 defining source file is the main source file of the compilation unit
 whose 'struct symtab' the 'struct symbol' appears in.  (This logic
 appears in linespec.c:decode_variable, and its call to
 'symbol_found'.)
 
 In the test program, however, 'bar' is defined on line 3 of the header
 file test.h, which is #included from the main file test.c.  This is
 why 'list bar' lists the correctly numbered lines --- of the wrong
 file.
 
 For functions, GDB actually looks up the symbol's entry point address
 in the full line table, which is better about tracking code into
 header files.  That's why 'list func' works, even though 'func' is
 declared in the header file, like 'bar'.
 
 I don't see any quick way to fix this problem: I think GDB's internal
 data structures just don't currently contain the information needed to
 do the job right.  One solution that comes to mind would be to extend
 the line table to map data addresses, as well as code addresses, to
 source locations.  Then we could drop the 'line' field of 'struct
 symbol', too.  But that's a big project.
 
 (I shouldn't take responsibility for this bug before making some more
 progress on some older bugs that I've already accepted.)