Re: [patch] Do not add partial_symbol again and again to the list

[Daniel Jacobowitz <drow@false.org>]

On Mon, Feb 11, 2008 at 05:10:14PM -0500, Aleksandar Ristovski wrote:
> unsigned int
> _GCC_ATTR_ALIGN_64t
> long long int
> _GCC_ATTR_ALIGN_u64t
> long long unsigned int
> _Int64t

OK, I remember what's going on now.  I think you've missed something
about these lists.

Suppose we've got two C files combined into one objfile by the linker.
One has "typedef long long _Int64t" and the other has "typedef struct
{ int hi, int lo; } _Int64t".  GDB records that type as present in
both files.  All the partial symbol says is that there's a typedef
named _Int64t; it doesn't say what it's typedef'd to.  Because it's
a typedef, the DWARF-2 reader adds it to the list of file-scope
symbols.

There's a single list of file-scope partial symbols for the whole
objfile, objfile->static_psymbols.  Each psymtab has an offset
(statics_offset) saying where in that file-wide list of symbols to
look for static symbols for this particular file.  So it's a single
"list", but it contains many individual lists.  That's why there's
a bcache; many files may have identical psymbols, but the psymbol
belongs to each individual file.

Your patch leaves the types out of every file after the first.  I
believe it will cause GDB to fail to locate the correct type or
enumerator.  Functions will be unaffected, since the psymbol includes
the address, so there won't be duplicates anyway.  We don't know
at this stage of processing if the typedef, struct, or enumerator
in the new file has the same value as the one in the previous file;
we don't have values until we read in full symbols.

-- 
Daniel Jacobowitz
CodeSourcery