From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11299 invoked by alias); 16 Aug 2012 15:23:14 -0000 Received: (qmail 11288 invoked by uid 22791); 16 Aug 2012 15:23:13 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Aug 2012 15:22:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D158E1C6495 for ; Thu, 16 Aug 2012 11:22:58 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 66K83OOsNnsn for ; Thu, 16 Aug 2012 11:22:58 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9F8E91C6492 for ; Thu, 16 Aug 2012 11:22:58 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id DB7AD14561A; Thu, 16 Aug 2012 08:22:55 -0700 (PDT) Date: Thu, 16 Aug 2012 15:23:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: RFC: printing pointers to global (data) variable on Windows... Message-ID: <20120816152255.GA2836@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00453.txt.bz2 Hello, I have a piece of code that defines a struct with one of the fields being a "char *". The field gets set to a global variable: char my_name[] = "MyName"; k = {my_name, [...]}; When trying to print key.system_name on Windows, we get: (gdb) p k.system_name $2 = 0x403000 "MyName" We're missing the reference to the global "my_name". On GNU/Linux, we get: (gdb) p k.system_name $3 = 0x6008e8 "MyName" I couldn't understand why this wasn't working, since GDB does not seem to have any problems determining what symbol is at 0x403000: (gdb) info symbol 0x403000 my_name in section .data of c:\[...]\lb.exe Debugging GDB, I found the following block of code in build_address_symbolic: if (msymbol != NULL && MSYMBOL_SIZE (msymbol) == 0 && MSYMBOL_TYPE (msymbol) != mst_text && MSYMBOL_TYPE (msymbol) != mst_text_gnu_ifunc && MSYMBOL_TYPE (msymbol) != mst_file_text) msymbol = NULL; Basically, build_address_symbolic searches for symbol names two ways: through the minimal symbols, and through the symbol table, but only function symbols: msymbol = lookup_minimal_symbol_by_pc_section (addr, section); symbol = find_pc_sect_function (addr, section); I looked at the COFF/PE documentation, and I do not think that there is a way to provide the size of each symbol in the symbol table. So the block of code above discards our minimal symbol entry due to the size (always) being zero. And since our global is not a function, we do not find anything from the debugging info either. Does anyone know why we have the block discarding zero-sized non-text symbols? I ran the testsuite on x86_64-linux, and got no regression. My second question is regarding the fact that we looking symbols for functions only. This probably made sense if the function was used for text addresses (like disass), but does it now? Or perhaps it's the GNU/Linux output that should be fixed, and only text symbols should be printed when printing addresses (somehow, I do not think that this would be right). At the moment, I am thinking that the proper fix would probably be two ways: ditch the block discarding zero-sized non-text symbols (this breaks with symbol tables whose format do not allow for symbol sizes), and also search all global symbols, rather than just functions. Thoughts? Thank you, -- Joel PS: I do not think that the problem is specific to the fact that this is a field inside a struct. I am pretty sure that the same would happen with a simple "char *" variable. But that's what I used for my investigation.