From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16469 invoked by alias); 9 May 2006 11:58:56 -0000 Received: (qmail 16458 invoked by uid 22791); 9 May 2006 11:58:55 -0000 X-Spam-Check-By: sourceware.org Received: from smtp18.wanadoo.fr (HELO smtp18.wanadoo.fr) (193.252.22.126) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 May 2006 11:58:49 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1802.wanadoo.fr (SMTP Server) with ESMTP id E01FC7000041 for ; Tue, 9 May 2006 13:58:46 +0200 (CEST) Received: from w98.wanadoo.fr (AMarseille-252-1-59-153.w86-193.abo.wanadoo.fr [86.193.162.153]) by mwinf1802.wanadoo.fr (SMTP Server) with ESMTP id C98C970000BA; Tue, 9 May 2006 13:58:45 +0200 (CEST) X-ME-UUID: 20060509115845825.C98C970000BA@mwinf1802.wanadoo.fr Message-Id: <6.1.0.6.0.20060509134912.00a10360@pop.wanadoo.fr> X-Sender: jr.peulve@pop.wanadoo.fr X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 09 May 2006 12:34:00 -0000 To: Nathan Sidwell From: Jean-Rene Peulve Subject: Re: gdbserver for m68k-uclinux Cc: gdb@sources.redhat.com, Daniel Jacobowitz In-Reply-To: <446069FB.40200@codesourcery.com> References: <445F5278.3000900@codesourcery.com> <6.1.0.6.0.20060509114307.00a0e780@pop.wanadoo.fr> <446069FB.40200@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00085.txt.bz2 Hi Natan, Sorry you were right. No need for my extra return. I did not spot the=20 return just below ! About my extra fprintf on the target console: I am also debugging kernel modules and I am used to specify the=20 add-symbol-file for several of them in adition to the kernel. For gdbserver, I was using one gdb command file to debug several=20 applications then when I start gdb I didn't specify the file to debug in the command line and then I used= =20 add-symbol-file afterward. With your remark in mind, I try to specify the application to debug in the= =20 command line and you are also right: the extra fprintf is not mandatory but= =20 I need to spend more time on it to see if there is any need left. Jean-Ren=E9 At 12:07 09/05/06, Nathan Sidwell wrote: >Jean-Rene Peulve wrote: >>Hi Nathan, >>Oups: I resend this because the previous email was html and got bounced=20 >>by gdb@sources.redhat.com > >Thanks for testing the patch out! > >>I have been forced to change your patch to make it works. >>1) missing return in server.c >The return you've added is unnecessary. > >>2) I also add an fprintf to stderr with the address of the text and data= =20 >>section to allow the use of add-symbol_file command which requires these= =20 >>address. >> The response to qOffsets being hidden by gdb, I then can get it from=20 >> the target console or telnet. > >Dan, I'll leave this change for you to decide. I don't understand the=20 >usage here. Why is it not necessary to know the text_end address in this= =20 >case, for instance? > >>+ if (the_target->read_offsets (&text, &data)) { >>+ sprintf (own_buf, "Text=3D%lX;Data=3D%lX;Bss=3D%lX", >>+ (long)text, (long)data, (long)data); >>+ return; >This return is not needed, why did you find it necessary? > >>+ } >>+ else >>+ write_enn (own_buf); >>+ >>+ return; >>+ } > >nathan > >-- >Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery >nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.= uk