From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10569 invoked by alias); 30 May 2012 21:36:05 -0000 Received: (qmail 10405 invoked by uid 22791); 30 May 2012 21:36:04 -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; Wed, 30 May 2012 21:35:45 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4ULZi4f027119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 May 2012 17:35:44 -0400 Received: from host2.jankratochvil.net (ovpn-116-47.ams2.redhat.com [10.36.116.47]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4ULZeWg003153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 May 2012 17:35:43 -0400 Date: Wed, 30 May 2012 21:36: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: <20120530213539.GA32534@host2.jankratochvil.net> References: 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-05/txt/msg00145.txt.bz2 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. It is more questionable why you cannot insert such breakpoint. Maybe also GDB could try hardware breakpoint if software breakpoint fails due to read-only memory. Regards, Jan