From: Aleksandar Ristovski <aristovski@qnx.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Do not add partial_symbol again and again to the list
Date: Mon, 11 Feb 2008 22:43:00 -0000 [thread overview]
Message-ID: <47B0CF8A.6080306@qnx.com> (raw)
In-Reply-To: <20080211223056.GA3833@caradoc.them.org>
Daniel Jacobowitz wrote:
> 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'.
next prev parent reply other threads:[~2008-02-11 22:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-11 20:23 Aleksandar Ristovski
2008-02-11 20:38 ` Daniel Jacobowitz
2008-02-11 20:52 ` Aleksandar Ristovski
2008-02-11 21:09 ` Daniel Jacobowitz
2008-02-11 21:41 ` Aleksandar Ristovski
2008-02-11 21:48 ` Daniel Jacobowitz
2008-02-11 22:10 ` Aleksandar Ristovski
2008-02-11 22:31 ` Daniel Jacobowitz
2008-02-11 22:43 ` Aleksandar Ristovski [this message]
2008-02-11 22:53 ` Daniel Jacobowitz
2008-02-12 1:08 ` Aleksandar Ristovski
2008-02-12 2:12 ` Daniel Jacobowitz
2008-02-12 5:35 ` Aleksandar Ristovski
2008-02-12 13:26 ` Daniel Jacobowitz
2008-02-12 15:54 ` Aleksandar Ristovski
2008-02-13 5:23 ` Aleksandar Ristovski
2008-02-14 1:31 ` Aleksandar Ristovski
2008-05-02 18:11 ` Aleksandar Ristovski
2008-05-03 21:32 ` Daniel Jacobowitz
2008-05-05 19:41 ` Aleksandar Ristovski
2008-05-05 19:38 ` Aleksandar Ristovski
2008-05-06 15:47 ` Daniel Jacobowitz
2008-05-06 18:45 ` Aleksandar Ristovski
2008-05-06 18:39 ` Aleksandar Ristovski
2008-05-06 18:50 ` Daniel Jacobowitz
2008-05-07 8:22 ` Aleksandar Ristovski
2008-05-07 9:01 ` Aleksandar Ristovski
2008-06-05 18:17 ` Daniel Jacobowitz
2008-06-05 19:26 ` Aleksandar Ristovski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47B0CF8A.6080306@qnx.com \
--to=aristovski@qnx.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox