From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22355 invoked by alias); 31 May 2012 13:26:04 -0000 Received: (qmail 22286 invoked by uid 22791); 31 May 2012 13:26:03 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,KHOP_THREADED,RDNS_NONE X-Spam-Check-By: sourceware.org Received: from Unknown (HELO gw1.transmode.se) (195.58.98.146) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 31 May 2012 13:24:43 +0000 Received: from mail1.transmode.se (mail1.transmode.se [192.168.201.18]) by gw1.transmode.se (Postfix) with ESMTP id 98D74258005; Thu, 31 May 2012 15:24:34 +0200 (CEST) In-Reply-To: References: <20120530213539.GA32534@host2.jankratochvil.net> Subject: Re: GDB 7.4 adds shlib_events BPs, casuing problem in debugging vmlinux X-KeepSent: 86B54A76:C7415654-C1257A0F:00499BBE; type=4; name=$KeepSent To: Joakim Tjernlund Cc: Jan Kratochvil , gdb@sourceware.org Message-ID: From: Joakim Tjernlund Date: Thu, 31 May 2012 13:26: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/msg00157.txt.bz2 Joakim Tjernlund/Transmode wrote on 2012/05/31 00:36:18: > > 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) With this small patch it works both cases: --- remote.c.org 2012-05-31 12:45:04.655541485 +0200 +++ remote.c 2012-05-31 15:21:24.273296844 +0200 @@ -3293,7 +3293,7 @@ /* Now, if we have thread information, update inferior_ptid. */ inferior_ptid = remote_current_thread (inferior_ptid); - remote_add_inferior (ptid_get_pid (inferior_ptid), -1); + remote_add_inferior (ptid_get_pid (inferior_ptid), 1); /* Always add the main thread. */ add_thread_silent (inferior_ptid); What do you think? Jocke