From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122854 invoked by alias); 19 Mar 2015 18:38:11 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 122830 invoked by uid 48); 19 Mar 2015 18:38:10 -0000 From: "wingo at igalia dot com" To: gdb-prs@sourceware.org Subject: [Bug symtab/18148] New: Definitions with DW_AT_const_value never make it into the psymtabs Date: Thu, 19 Mar 2015 19:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: wingo at igalia dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-q1/txt/msg00470.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=18148 Bug ID: 18148 Summary: Definitions with DW_AT_const_value never make it into the psymtabs Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: symtab Assignee: unassigned at sourceware dot org Reporter: wingo at igalia dot com LLVM will not allocate storage for the "foo" in "static const int foo = 1". Instead it inlines the value at the use sites, and emits a DW_TAG_variable with DW_AT_const_value for the definition of "foo". GCC will allocate storage for both at -O0 but at -O2 the same problem exists. Unfortunately, partial debug info (PDI) instances without a location don't get added to the psymtabs table. That means that if you do the following: cat < one.c static const int one = 1; extern int fetch_two (void); int main (int argc, char *argv[]) { return one + fetch_two (); } EOF cat < two.c static const int two = 2; int fetch_two (void) { return two; } EOF gcc -g -O2 -c -o one.o one.c gcc -g -O2 -c -o two.o two.c gcc -g -o test one.o two.o gdb ./test Then at the GDB prompt: (gdb) p one $1 = 1 (gdb) p two No symbol "two" in current context. The reason we can get "one" and not "two" is because the symtab for one.c has been expanded, when we went to look for main. If we expand the compilation unit for two.c and flush the symbol cache, if on GDB trunk: (gdb) mt expand foo.c # only needed on trunk (gdb) mt flush-symbol-cache (gdb) print two $2 = 2 The ultimate cause is that dwarf2read.c:add_partial_symbol punts if the symbol has no location, thinking it's a declaration and not a definition. Well if it has a DT_AT_const_value, it might be a definition too. Patch coming tomorrow. -- You are receiving this mail because: You are on the CC list for the bug.