From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13138 invoked by alias); 3 Apr 2012 08:30:52 -0000 Received: (qmail 13110 invoked by uid 22791); 3 Apr 2012 08:30:50 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Apr 2012 08:30:39 +0000 From: "jakub at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug symtab/11717] common/.bss variables from shared libraries not displayed correctly Date: Tue, 03 Apr 2012 08:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 7.1 X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2012-q2/txt/msg00013.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11717 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at redhat dot com --- Comment #4 from Jakub Jelinek 2012-04-03 08:30:08 UTC --- (In reply to comment #3) > As the test case shows, this problem is not limited to unintialized variables > in .bss -- it also occurs with initialized variables in .data. > > The basic problem is that the DW_AT_location for the variable in the shared > library is incorrect, since it does not match how the variable is accessed. It > says that var is addressed directly, while in fact it is accessed indirectly > through the GOT. > > GCC generates > DW_OP_addr var > which points to the unused copy of var in the shared library. The correct > DWARF should be > DW_OP_addr var@GOT > DW_OP_deref Unfortunately, that has a couple of problems: 1) we don't want to generate runtime overhead just for debugging, so the above would "work" only if we have some other GOT reference to that symbol in the code 2) on most targets we don't have suitable relocations that would give us the address of the GOT slot Even DW_OP_addr var@GOT DW_OP_addr _GLOBAL_OFFSET_TABLE_ DW_OP_plus DW_OP_deref doesn't work on x86_64, while var@GOT in that case gives the relative offset from _GLOBAL_OFFSET_TABLE_ to the GOT entry for var, unfortunately _GLOBAL_OFFSET_TABLE_ symbol is handled specially and thus becomes a wrong kind of relocation. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.