From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13419 invoked by alias); 2 May 2015 09:48:48 -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 13405 invoked by uid 89); 2 May 2015 09:48:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_40,RCVD_IN_DNSWL_NONE,RCVD_IN_JMF_BL,SPF_PASS autolearn=no version=3.3.2 X-HELO: mailrelay107.isp.belgacom.be Received: from mailrelay107.isp.belgacom.be (HELO mailrelay107.isp.belgacom.be) (195.238.20.134) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 02 May 2015 09:48:45 +0000 X-Belgacom-Dynamic: yes X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=pojTLeLEEG+IB9MeyQ9xnWKWJHiyH+4Hnj5iAYu/pCk= c=1 sm=2 a=IkcTkHD0fZMA:10 a=DvrHy-GDgqKTydw5U6YA:9 a=QEXdDO2ut3YA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CUAQBtnERV/7LMgG0NT4dYzD0BAQEBAQGFVYELAiYCiSKyInCTQoEhjzqCUoFFBZ1mhj6OJYIIIhyBU4MyAQEB Received: from 178.204-128-109.adsl-dyn.isp.belgacom.be (HELO [192.168.1.10]) ([109.128.204.178]) by relay.skynet.be with ESMTP; 02 May 2015 11:48:42 +0200 Subject: qXfer:exec-file:read and non multiprocess target From: Philippe Waroquiers To: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" Date: Sat, 02 May 2015 09:48:00 -0000 Message-ID: <1430560118.11263.9.camel@soleil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00016.txt.bz2 I am busy adding qXfer:exec-file:read to the Valgrind gdbserver. Even if Valgrind reports it supports qXfer:exec-file, GDB does not query it. This is due to the fact that GDB does not query the exec-file when the pid is a fake pid, which is the case for Valgrind, as the target command to use is: target remote | vgdb The following change in remote.c ensures GDB queries the remote exec-file: 1561,1562c1561,1562 < if (try_open_exec && !fake_pid_p && get_exec_file (0) == NULL) < exec_file_locate_attach (pid, 1); --- > if (try_open_exec && get_exec_file (0) == NULL) > exec_file_locate_attach (fake_pid_p ? 0 : pid, 1); With that change, GDB can use a Valgrind target without having to specify the exec file. The idea is that when the stub gets a pid 0 in this request, it replies with the exec file of the current process. I have not yet investigated a remaining problem: if the same GDB does first a target remote|vgdb and gets as exec-file firstexecfile, then after the first target has terminated, a second target remote|vgdb for another process does not re-query the exec file : GDB uses the first exec file, even if the second target has another file. Feedback about allowing the exec-file of a fake pid to be queried ? Philippe