From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32482 invoked by alias); 12 Feb 2016 17:31:04 -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 32460 invoked by uid 89); 12 Feb 2016 17:31:03 -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=cmdline, crafted, Hx-languages-length:1934, restart 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; Fri, 12 Feb 2016 17:31:02 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1aUHYY-0002ER-W0 from Luis_Gustavo@mentor.com ; Fri, 12 Feb 2016 09:30:59 -0800 Received: from [172.30.0.195] (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; Fri, 12 Feb 2016 09:30:58 -0800 Reply-To: Luis Machado Subject: Re: [PATCH] Remote debugging without a binary (regression) References: <1455200365-5270-1-git-send-email-lgustavo@codesourcery.com> <56BDFA73.9000001@redhat.com> <56BE038E.3060406@codesourcery.com> <56BE0A1D.2070408@redhat.com> To: Pedro Alves , CC: From: Luis Machado Message-ID: <56BE16CB.8050309@codesourcery.com> Date: Fri, 12 Feb 2016 17:31: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: <56BE0A1D.2070408@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00421.txt.bz2 On 02/12/2016 02:36 PM, Pedro Alves wrote: > On 02/12/2016 04:08 PM, Luis Machado wrote: > >> I did not exercise that, but did not discard it either. I was attempting >> to solve one problem at a time. There may be a failure there too. > > I matters to determine where the TRY/CATCH should go, or even whether > the fix should be to not throw in the first place. > Ok, i crafted a test application that i can attach to via a remote gdbserver and through the extended remote protocol. I see the same error as before. On GDB's side, for example: -- /lib64/ld-2.22.so: No such file or directory. (gdb) -- But it seems we have already attached to the process by the time we error out. So we remain attached to it, just not sure if in a sane state: -- (gdb) info proc process 5464 warning: target file /proc/5464/cmdline contained unexpected null characters cmdline = '/lib64/ld.so.1' cwd = '/home/tester' exe = '/lib64/ld-2.22.so' (gdb) i r zero at v0 v1 a0 a1 a2 a3 R0 000013aa 00000014 00000204 00000000 ffa831f8 ffa831f8 00000000 00000001 t0 t1 t2 t3 t4 t5 t6 t7 R8 ffa83060 557da7e0 00000000 015555f7 00000000 00000000 801123d8 00000000 s0 s1 s2 s3 s4 s5 s6 s7 R16 ffa83178 00020000 ffa830f8 00000000 00503bd8 00000000 004ee308 00000000 t8 t9 k0 k1 gp sp s8 ra R24 00000038 55700e4c 00000000 00000000 557da7e0 ffa83000 ffa83240 55700ba0 status lo hi badvaddr cause pc 0400a4f3 00000000 00000017 557a20e4 00800020 55700e78 fcsr: 0x0 fir: 0x173890c restart: 0x13aa (gdb) -- > Like, with: > > (gdb) define foo >> attach PID >> info threads >> end > (gdb) foo > > should failing to load the executable error out before > reaching "info threads", or continue. > > I think it should not error out, like we don't error out > if the target doesn't support target_pid_to_exec_file > at all. Agreed. In this case "info threads" doesn't run at all. > > Thanks, > Pedro Alves >