From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12096 invoked by alias); 16 Nov 2006 20:53:19 -0000 Received: (qmail 12049 invoked from network); 16 Nov 2006 20:53:06 -0000 Received: from unknown (195.23.133.224) by sourceware.org with QMTP; 16 Nov 2006 20:53:06 -0000 Received: (qmail 4300 invoked from network); 16 Nov 2006 20:53:05 -0000 Received: from unknown (HELO mailfrt06.isp.novis.pt) ([195.23.133.198]) (envelope-sender ) by mailrly04.isp.novis.pt with compressed SMTP; 16 Nov 2006 20:53:05 -0000 Received: (qmail 28436 invoked from network); 16 Nov 2006 20:53:04 -0000 Received: from unknown (HELO [192.168.0.35]) ([195.23.225.143]) (envelope-sender ) by mailfrt06.isp.novis.pt with SMTP; 16 Nov 2006 20:53:04 -0000 Message-ID: <455CCFAD.6060407@portugalmail.pt> Date: Thu, 16 Nov 2006 20:53:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Crash in write_exp_msymbol for coff targets. Content-Type: multipart/mixed; boundary="------------040701080609050108010003" X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00148.txt.bz2 This is a multi-part message in MIME format. --------------040701080609050108010003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 884 Hi all, The TLS without debugging info support introduced a bug for coff based targets. While printing for example a global symbol's value I am getting a segfault in parse.c:write_exp_msymbol, at: if (SYMBOL_BFD_SECTION (msymbol)->flags & SEC_THREAD_LOCAL) The problem is that minimal symbols may not have a bfd section set. The attached patch fixes it, but is it correct? I see in coffread.c, that prim_record_minimal_symbol_and_info is always called with a NULL bfd section, whilst in elfread.c, is is not. Is this a limitation of the coff format? Should coffread.c be fixed instead? I caught this while running the testsuite for the arm-wince gdbserver port I am working on. Cheers, Pedro Alves --- 2006-11-16 Pedro Alves * parse.c (write_exp_msymbol): Check if SYMBOL_BFD_SECTION (msymbol) is NULL before dereferencing it. --------------040701080609050108010003 Content-Type: text/plain; name="nodeb.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nodeb.diff" Content-length: 457 --- parse.c.org 2006-11-16 20:37:10.000000000 +0000 +++ parse.c 2006-11-16 00:19:52.000000000 +0000 @@ -408,7 +408,8 @@ write_exp_msymbol (struct minimal_symbol write_exp_elt_opcode (OP_LONG); - if (SYMBOL_BFD_SECTION (msymbol)->flags & SEC_THREAD_LOCAL) + if (SYMBOL_BFD_SECTION (msymbol) + && (SYMBOL_BFD_SECTION (msymbol)->flags & SEC_THREAD_LOCAL)) { bfd *bfd = SYMBOL_BFD_SECTION (msymbol)->owner; struct objfile *ofp; --------------040701080609050108010003--