From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19035 invoked by alias); 7 Apr 2003 16:02:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19027 invoked from network); 7 Apr 2003 16:02:07 -0000 Received: from unknown (HELO ns2.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 7 Apr 2003 16:02:07 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by ns2.uk.superh.com (8.11.6+Sun/8.11.6) with ESMTP id h37Fg3x20213 for ; Mon, 7 Apr 2003 16:42:03 +0100 (BST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: Attaching to a running process Date: Mon, 07 Apr 2003 16:02:00 -0000 Message-ID: <9FF3133289A7A84E81E2ED8F5E56B379604385@sh-uk-ex01.uk.w2k.superh.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Thomas,Stephen" To: Cc: "McGoogan,Sean" X-SW-Source: 2003-04/txt/msg00062.txt.bz2 Hi, I am currently working on a port of gdb to SuperH SH64 Linux, & I am having= a problem with the gdb 'attach' command. According to the gdb info pages, = gdb is supposed to work out what filename the attached process is running, = & load its symbols. However, gdb doesn't seem to be doing this. I checked o= ur x86 gdb, & that doesn't either (gdb version number reported as 'Red Hat = Linux 7.x (5.0rh-15)'). On x86 this doesn't seem to matter much. However it does on SH64, as the at= tach seems to get done using some default target info, which means it gets = the wrong CPU type and the wrong endianess. If I tell gdb what filename to = use (e.g. by specifying it on the command line), everything works fine. So should gdb try to find the filename & load it before attaching or not? I= f not (i.e. the info pages are wrong), then I guess I'm going to have to so= lve this somehow...=20 Steve Thomas SuperH (UK) Ltd.