From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21883 invoked by alias); 30 May 2012 22:36:35 -0000 Received: (qmail 21727 invoked by uid 22791); 30 May 2012 22:36:34 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from gw1.transmode.se (HELO gw1.transmode.se) (195.58.98.146) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 May 2012 22:36:20 +0000 Received: from mail1.transmode.se (mail1.transmode.se [192.168.201.18]) by gw1.transmode.se (Postfix) with ESMTP id 7A9F9258021; Thu, 31 May 2012 00:36:19 +0200 (CEST) In-Reply-To: <20120530213539.GA32534@host2.jankratochvil.net> References: <20120530213539.GA32534@host2.jankratochvil.net> Subject: Re: GDB 7.4 adds shlib_events BPs, casuing problem in debugging vmlinux X-KeepSent: 4E766EE5:67CABBE6-C1257A0E:007AF1CF; type=4; name=$KeepSent To: Jan Kratochvil Cc: gdb@sourceware.org Message-ID: From: Joakim Tjernlund Date: Wed, 30 May 2012 22:36:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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/msg00146.txt.bz2 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" No it is not. There are no shared libs in vmlinux, not even an interpreter Seems to me that gdb tries too hard, it should stop if there is no "_r_debug_state" or at least exclude _start from the list, should be enough with main. > 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. There are no DT_NEEDED either, the dynamic section is not there. > "_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 Not when when using an emulator which will start from CPU reset and therefore there is no RAM mapped at all. > could try hardware breakpoint if software breakpoint fails due to read-only > memory. Yes I can do that but that doesn't solve the problem completely, the hidden BP will consume one HW BP resource which I never get back. I only got 2 HW BPs so I don't want to waste them. Looking at: if (!current_inferior ()->attach_flag) it is clear to me that this is not supposed to be executed if I am attached. A quick test revels: # > gdb (gdb) tar rem bdi:2001 (gdb) file vmlinux (gdb) maintenance info breakpoints (gdb) Now there is no BP so the attached test does not work when you start gdb with vmlinux as argument(the most common use) Jocke