From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29404 invoked by alias); 1 Jun 2012 14:48:23 -0000 Received: (qmail 29396 invoked by uid 22791); 1 Jun 2012 14:48:21 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,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; Fri, 01 Jun 2012 14:48:05 +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 q51Em5tw031632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jun 2012 10:48:05 -0400 Received: from host2.jankratochvil.net (ovpn-116-47.ams2.redhat.com [10.36.116.47]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q51Em1KZ005407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 1 Jun 2012 10:48:04 -0400 Date: Fri, 01 Jun 2012 14:48:00 -0000 From: Jan Kratochvil To: Joakim Tjernlund Cc: gdb@sourceware.org Subject: Re: GDB 7.4 adds shlib_events BPs, casuing problem in debugging vmlinux Message-ID: <20120601144801.GA26669@host2.jankratochvil.net> References: <20120530213539.GA32534@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00002.txt.bz2 On Thu, 31 May 2012 02:31:17 +0200, Joakim Tjernlund wrote: > Jan Kratochvil wrote on 2012/05/30 23:35:39: > > On Wed, 30 May 2012 16:25:29 +0200, Joakim Tjernlund wrote: > > > Found this in solib-svr4.c which I think is the problem: > > > static const char * const bkpt_names[] = > > > { > > > "_start", > > > "__start", > > > "main", > > > NULL > > > }; > > > ... > > > ... > > > if (!current_inferior ()->attach_flag) > > > { > > > for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++) > > > { > > > msymbol = lookup_minimal_symbol (*bkpt_namep, NULL, symfile_objfile); > > > if ((msymbol != NULL) && (SYMBOL_VALUE_ADDRESS (msymbol) != 0)) > > > { > > > sym_addr = SYMBOL_VALUE_ADDRESS (msymbol); > > > sym_addr = gdbarch_convert_from_func_ptr_addr (target_gdbarch, > > > sym_addr, > > > ¤t_target); > > > create_solib_event_breakpoint (target_gdbarch, sym_addr); > > > return 1; > > > } > > > } > > > } > > > > > > This will insert the above BP just because the symbol _start is present. Seems like > > > there are missing safe guards to avoid the unwanted BP > > > > This breakpoint is wanted. If GDB fails to insert the "_r_debug_state" > > breakpoint into ld.so for whatever reason then after initial DT_NEEDED loading > > of shared libraries ld.so gives away control to the main executable. > > "_start" is the possible symbol there how to catch just exit from ld.so. > > BTW, if this is all about ld.so, then why not guard this with > if (interp_name) /* Check if there is a ld.so at all */ > { > ... > } Yes, I think this should work - to omit "_start" and "__start" if there is no INTERP_NAME. Thanks, Jan