From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14143 invoked by alias); 8 Feb 2012 21:21:34 -0000 Received: (qmail 14131 invoked by uid 22791); 8 Feb 2012 21:21:33 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Feb 2012 21:21:14 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q18LLDA8017732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Feb 2012 16:21:13 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q18LLCL1019961; Wed, 8 Feb 2012 16:21:12 -0500 Message-ID: <4F32E748.5020608@redhat.com> Date: Wed, 08 Feb 2012 21:21:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org Subject: Re: [patch] Fix crash on `info files' with gdbserver References: <20120208204955.GA28565@host2.jankratochvil.net> In-Reply-To: <20120208204955.GA28565@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-02/txt/msg00115.txt.bz2 On 02/08/2012 08:49 PM, Jan Kratochvil wrote: > while playing with gdbserver GDB just crashed for me. > > The problem is exec_ops get pushed to the target stack for the loaded shared > libraries despite exec_bfd remains NULL which is not expected by exec.c. > > Breakpoint 1, add_target_sections (sections=0x21372e0, sections_end=0x2137580) at exec.c:471 > 471 push_target (&exec_ops); > (gdb) bt > #0 add_target_sections (sections=0x21372e0, sections_end=0x2137580) at exec.c:471 > #1 in solib_map_sections (so=0x21cd6f0) at solib.c:507 > #2 in update_solib_list (from_tty=1, target=0x1d8fee0) at solib.c:804 > #3 in solib_add (pattern=0x0, from_tty=1, target=0x1d8fee0, readsyms=1) at solib.c:889 > #4 in enable_break (info=0x210f000, from_tty=1) at solib-svr4.c:1624 > #5 in svr4_solib_create_inferior_hook (from_tty=1) at solib-svr4.c:2234 > #6 in solib_create_inferior_hook (from_tty=1) at solib.c:1172 > #7 in reload_shared_libraries (ignored=0x0, from_tty=1, e=0x1fc5cd0) at solib.c:1308 > > So it is questionable whether to keep exec_ops unpushed or whether to handle > NULL exec_bfd there. I chose the latter. That's the right choice. The exec target nowadays handles reading memory from all target sections, no matter whether they came from the executable or from shared libraries. So e.g., "set trust-readonly-sections" works with the DSOs target sections too. -- Pedro Alves