From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14307 invoked by alias); 11 Aug 2011 01:34:34 -0000 Received: (qmail 13459 invoked by uid 22791); 11 Aug 2011 01:34:32 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,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; Thu, 11 Aug 2011 01:34:16 +0000 Received: (qmail 21879 invoked from network); 11 Aug 2011 01:34:15 -0000 Received: from unknown (HELO ?192.168.0.101?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Aug 2011 01:34:15 -0000 Message-ID: <4E433193.3050708@codesourcery.com> Date: Thu, 11 Aug 2011 01:34:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: chandra krishnappa CC: gdb-patches@sourceware.org Subject: Re: [PATCH] arm reversible : References: <1312996122.92588.YahooMailClassic@web36104.mail.mud.yahoo.com> In-Reply-To: <1312996122.92588.YahooMailClassic@web36104.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-08/txt/msg00229.txt.bz2 On 08/11/2011 01:08 AM, chandra krishnappa wrote: > Kindly suggest some steps or operations which confirms the basic host and target communication is working fine.. > > I am stuck up with connection itself.... > > 1. Copied "gdbserver" ( ARM compiled ) on to target board. > ./gdbserver 192.168.1.2:9876 ../from_host/test_arm > > 2. start gdb from host system > personal@computer:~/Desktop/gdb-7.3/gdb-7.3$ ./gdb/gdb > GNU gdb (GDB) 7.3 > Copyright (C) 2011 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux". > For bug reporting instructions, please see: > . > (gdb) target remote 192.168.1.6:9876 > Remote debugging using 192.168.1.6:9876 > warning: Can not parse XML target description; XML support was disabled at compile time > 0x400007b0 in ?? () > (gdb) continue > Continuing. > Cannot access memory at address 0x0 > [Inferior 1 (Remote target) exited normally] > > Your step 2 looks incorrect to me. You should fire gdb with debuggee program, like ./gdb test_arm. > > On the remote target the complete program is just executing and showing the results... > > Not able to debug the program step by step not even any break.. > > Am searching for some step by step host : target gdb setup through cris-cross cables... > > I dont have serial port on my laptop, generally there are more articles on serial connections... seems that used by most .. > Your connection between host gdb and gdbserver works. serial port is usually used to connect with bare mental board which doesn't have network connection. You don't need to have a serial port in this case. > > Parallel I am looking at running dejagnu testsuite for x86 locally.. thinking of extend the x86 execution method of connection of host and target for ARM Board.. > dejagnu naturally supports remote testing, so you don't have to invent the wheel again. What you need here is a board file. Here is an example, # gdbserver running over ssh. load_generic_config "gdbserver" process_multilib_options "" # The default compiler for this target on host machine. set_board_info compiler "/home/yao/toolchain/fsf-gcc-trunk/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc" set_board_info rsh_prog /usr/bin/ssh set_board_info rcp_prog /usr/bin/scp set_board_info protocol standard set_board_info hostname your.target.host.name or ip address set_board_info username yao # gdbserver's location on your target board. set_board_info gdb_server_prog /home/yao/gdbserver # We will be using the standard GDB remote protocol set_board_info gdb_protocol "remote" # Use techniques appropriate to a stub set_board_info use_gdb_stub 1 # This gdbserver can only run a process once per session. set_board_info gdb,do_reload_on_run 1 # There's no support for argument-passing (yet). set_board_info noargs 1 # Can't do input (or output) in the current gdbserver. set_board_info gdb,noinferiorio 1 # Can't do hardware watchpoints, in general set_board_info gdb,no_hardware_watchpoints 1 If your board has ssh, you can use this board file with minor changes (such as location of gdbserver and gcc). If your board doesn't have ssh, IIRC, dejagnu also support telnet and rsh to access remote boards. You can find more from google. You can save the board file as arm.exp, or whatever you prefer, and set dejagnu a little bit so that this board file can be used when you run `make check'. Please reference this wiki page on how to use a new board file in gdb tests. Testing gdbserver in a native configuration http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration -- Yao (齐尧)