From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24516 invoked by alias); 1 Jun 2012 14:39:13 -0000 Received: (qmail 24507 invoked by uid 22791); 1 Jun 2012 14:39:12 -0000 X-SWARE-Spam-Status: No, hits=-1.6 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; Fri, 01 Jun 2012 14:38:58 +0000 Received: from mail1.transmode.se (mail1.transmode.se [192.168.201.18]) by gw1.transmode.se (Postfix) with ESMTP id A5E0A258153; Fri, 1 Jun 2012 16:38:57 +0200 (CEST) In-Reply-To: <4FC8CCD7.9060800@redhat.com> References: <1338557804-20910-1-git-send-email-Joakim.Tjernlund@transmode.se> <4FC8CCD7.9060800@redhat.com> Subject: Re: [PATCH] remote: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot with Abatron BDI emulator an error occurs: X-KeepSent: 3AAFEC4B:204A4D0F-C1257A10:004FA84E; type=4; name=$KeepSent To: Pedro Alves Cc: gdb-patches@sourceware.org Message-ID: From: Joakim Tjernlund Date: Fri, 01 Jun 2012 14:39:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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-06/txt/msg00012.txt.bz2 Pedro Alves wrote on 2012/06/01 16:08:23: > > On 06/01/2012 02:36 PM, Joakim Tjernlund wrote: > > > .. > > (gdb) tar remote bdi:2001 > > Remote debugging using bdi:2001 > > 0xeff80050 in ?? () > > (gdb) mon reset > > (gdb) cont > > Continuing. > > Warning: > > Cannot insert breakpoint -1. > > Error accessing memory address 0xc0000000: Unknown error 4294967295. > > > > (gdb) maintenance info breakpoints > > Num Type Disp Enb Address What > > -1 shlib events keep y 0xc0000000 <_stext> inf 1 > > > > gdb mistakenly inserts a special shared library BP even though > > there area no such libs in either linux or u-boot. > > > GDB has no special knowledge of the Linux kernel, nor of u-boot. > A GNU/Linux targeted GDB (*-*-linux-gnu) recognizes, and knows how to > debug user space applications. If the kernel binary or the u-boot binary > look very much like GNU/Linux user space programs, the *-*-linux-gnu targeted > GDB will assume that's what they are. If you used a bare metal elf/eabi > targeted GDB, which is really what those programs are, you'd not see this. Yes you would, the error comes from this in solibsvr4.c: 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; } } } Just because a executable has a _start/__start/main in it, it doesn't mean it uses shared libs. I think this code assumes way too much, it is a last resort if everything else fails. The code tries to avoid attached targets but fails because it isn't attached yet > > > Fix this by explicitly informing remote_add_inferior() that > > the remote is attached. > > > NAK. This is not a "fix", it's papering over the problem, and > regresses GDB. It makes GDB always detach on quit, instead of asking > the remote end whether it is "attached" or whether it has "spawned" > the inferior. OK, that is fine. I don't know this code. Any suggestion ?