From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22372 invoked by alias); 12 Jan 2011 16:57:13 -0000 Received: (qmail 22361 invoked by uid 22791); 12 Jan 2011 16:57:12 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Jan 2011 16:57:07 +0000 Received: (qmail 3109 invoked from network); 12 Jan 2011 16:57:06 -0000 Received: from unknown (HELO ?10.155.3.22?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Jan 2011 16:57:06 -0000 Message-ID: <4D2DDD61.6040101@codesourcery.com> Date: Wed, 12 Jan 2011 17:23:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Pluzhnikov CC: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [patch] Add tests for JIT debugging interface References: <20110111232641.AE3D5190C55@elbrus2.mtv.corp.google.com> <4D2D3E94.4070509@codesourcery.com> <201101121003.37871.pedro@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2011-01/txt/msg00266.txt.bz2 On 01/12/2011 09:08 AM, Paul Pluzhnikov wrote: > On Wed, Jan 12, 2011 at 2:03 AM, Pedro Alves wrote: >> On Wednesday 12 January 2011 05:39:32, Yao Qi wrote: >>> Test cases work well in native GDB. Does gdbserver have JIT debugging >>> interface also? If not, we probably should skip this test for remote >>> mode or kfail it. >> >> The JIT debugging interface is all implemented in common code, >> so it should work against remote/gdbserver as well (though I haven't >> tried it). A gdb_load_shlibs call to copy the shlib to the >> target appears to be missing though. > > I tried running the test with gdbserver-native, and it failed, because > 'set args' doesn't work in server mode (AFAICT). > Yes, I also got some failures due to this. Then I hacked jit-main.c to set libname by an absolute path on my laptop, so no args are needed any more. There are still two failures, which are not about 'set args' in gdbserver. FAIL: gdb.base/jit.exp: info function jit_function FAIL: gdb.base/jit.exp: info function jit_function info function jit_function^M All functions matching regular expression "jit_function":^M (gdb) FAIL: gdb.base/jit.exp: info function jit_function In gdb.log, I find something strange, (gdb) continue^M Continuing.^M jit_inferior_init, registering_code = 0^M jit_inferior_init, reg_addr = 0x80486c4^M jit_inferior_init, jit_descriptor_addr = 0x804a040^M Cannot remove breakpoints because program is no longer writable. <-- [1] There is no such error [1] in native gdb test. I have no clue on this so far. > I grepped through *.exp in search of examples of how to run programs > that require args under gdbserver, but didn't find any. > > I want something like > > if {[is_remote host]} { > spawn gdbserver :2345 exe shlib 1 > } else { > spawn gdb --args exe shlib 1 > } > > Is there a "standard" way to achieve this? > >> You want notice it missing >> if you do the usual gdbserver running on the same machine as >> gdb testing (*). > > Right. I didn't get that far yet. > > Are there instructions for running with gdbserver on different host? We may re-write jit-main.c a little bit to compute the location of jit-solib.so via getcwd() + argv[0], rather than passing arguments of its location. -- Yao Qi