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

Aleksandar Ristovski
2008-02-11T22:43:44Z

> 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.
>

If one compilation unit has a list of symbols and they appear more than once...
do we really need to have all duplicate records in partial symbols list? The
partial symbol lookup (by symbol name) will find only the first one matching and
probably cause loading the full symbols at which point all works as before.

Not sure if it is a valid indicator but I didn't have any regressions in 'make
check'.