From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130362 invoked by alias); 11 Feb 2016 17:42:59 -0000 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 Received: (qmail 130347 invoked by uid 89); 11 Feb 2016 17:42:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=sitting, firing, gdb.server, UD:gdb.server X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Feb 2016 17:42:57 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1aTvGY-00011A-Bi from Luis_Gustavo@mentor.com ; Thu, 11 Feb 2016 09:42:54 -0800 Received: from [172.30.9.173] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Thu, 11 Feb 2016 09:42:53 -0800 Reply-To: Luis Machado Subject: Re: [PATCH] Remote debugging without a binary (regression) References: <1455200365-5270-1-git-send-email-lgustavo@codesourcery.com> <20160211163510.GA21352@blade.nx> <56BCBF8F.8040601@codesourcery.com> <56BCC583.1050209@redhat.com> To: Pedro Alves , Gary Benson CC: From: Luis Machado Message-ID: <56BCC817.70205@codesourcery.com> Date: Thu, 11 Feb 2016 17:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BCC583.1050209@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00383.txt.bz2 On 02/11/2016 03:31 PM, Pedro Alves wrote: > On 02/11/2016 05:06 PM, Luis Machado wrote: > >> Does that make it clear? > > Sounds like we're missing a test. Say, a test in gdb.server/ > that: > > #1 - does "set sysroot /dev/null" > #2 - connects > #3 - does "disassemble", "si", "info registers", or something. > > Sounds like we currently fail step #2. Steps #3 would be there just > to make sure the session is not semi-borked even if we connected > successfully. Yeah. Unfortunately that does not work well because GDB is smart enough to try and load the binary gdbserver loaded, which happens to be sitting in the same filesystem, so it won't fail. I also attempted to delete the binary right after firing gdbserver up, but it also does not fail, though GDB acknowledges now that the file has been deleted. The problematic scenario appears when one has two distinct filesystems. Say, one in each machine. Then GDB won't be able to load the symbol file and will error out. This is usually the case when one is doing Linux cross debugging.