From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20884 invoked by alias); 18 May 2005 16:01:56 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20401 invoked from network); 18 May 2005 16:01:46 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 18 May 2005 16:01:46 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DYQzQ-0002RU-It; Wed, 18 May 2005 12:01:44 -0400 Date: Wed, 18 May 2005 18:08:00 -0000 From: Daniel Jacobowitz To: Manoj Iyer Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] gdb.server testcases (resend) Message-ID: <20050518160144.GA9283@nevyn.them.org> Mail-Followup-To: Manoj Iyer , gdb-patches@sources.redhat.com References: <20050518012521.GB8672@nevyn.them.org> <20050518130218.GA11918@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00453.txt.bz2 On Wed, May 18, 2005 at 10:37:56AM -0500, Manoj Iyer wrote: > > Daniel, > > The patches did not apply cleanly to mainline, so I had to hand patch the > files. Also, in the final link stage for gdbserver ld complained that: > > /usr/bin/ld: warning: powerpc:common64 architecture of input file > `inferiors.o' is incompatible with powerpc:common output > > so I had to add a -m64 to the linker call. > > gdbserver still broken:. > > $ ./gdbserver uranus.ltc.austin.ibm.com /tmp/server > Process /tmp/server created; pid = 4747 > reading register 70: Input/output error > Exiting My reading of the kernel source suggests that FPSCR should be accessible using that address. You should figure out why it isn't. At a guess your headers are broken: /* NOTE: cagney/2005-02-08: On some 64-bit GNU/Linux systems the kernel headers incorrectly contained the 32-bit definition of PT_FPSCR. For the 32-bit definition, floating-point registers occupy two 32-bit "slots", and the FPSCR lives in the secondhalf of such a slot-pair (hence +1). For 64-bit, the FPSCR instead occupies the full 64-bit 2-word-slot and hence no adjustment is necessary. Hack around this. */ -- Daniel Jacobowitz CodeSourcery, LLC