From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21412 invoked by alias); 10 Apr 2008 18:00:54 -0000 Received: (qmail 21401 invoked by uid 22791); 10 Apr 2008 18:00:53 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1.sunquestinfo.com (HELO azbarracuda.sunquestinfo.com) (149.138.25.7) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Apr 2008 18:00:28 +0000 Received: from sqex4.sunquestinfo.com (localhost [127.0.0.1]) by azbarracuda.sunquestinfo.com (Spam Firewall) with ESMTP id 64C911B86AF for ; Thu, 10 Apr 2008 11:00:26 -0700 (MST) Received: from sqex4.sunquestinfo.com (sqex4.sunquestinfo.com [149.138.60.208]) by azbarracuda.sunquestinfo.com with ESMTP id OBuEUpeYX9pcCofo for ; Thu, 10 Apr 2008 11:00:26 -0700 (MST) Received: from SQMAILBOX1.sunquestinfo.com ([10.105.61.111]) by sqex4.sunquestinfo.com ([149.138.60.208]) with mapi; Thu, 10 Apr 2008 11:00:26 -0700 From: "Roberts, Dennis" To: "'gdb@sourceware.org'" Date: Thu, 10 Apr 2008 18:19:00 -0000 Subject: rs6000-tdep.c Question Message-ID: <4813EA4A50D35A44906A74A5E341D0B61A03388614@SQMAILBOX1.sunquestinfo.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-5.000.1023-15840.005 x-tm-as-result: No--40.316000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00085.txt.bz2 I'm trying to teach gdb to interpret 64-bit executables and core files on A= IX 5.3.0.0. I think I've got it working (I haven't found a way to break it= yet although I haven't tested it on any other versions of AIX), but I'm a = little uncomfortable with one of the code changes. Here's the original cod= e: if (!from_xcoff_exec) { arch =3D info.bfd_arch_info->arch; mach =3D info.bfd_arch_info->mach; } else { arch =3D bfd_arch_powerpc; bfd_default_set_arch_mach (&abfd, arch, 0); info.bfd_arch_info =3D bfd_get_arch_info (&abfd); mach =3D info.bfd_arch_info->mach; } Here's the new code: if (!from_xcoff_exec || wordsize =3D=3D 8) { arch =3D info.bfd_arch_info->arch; mach =3D info.bfd_arch_info->mach; } else { arch =3D bfd_arch_powerpc; bfd_default_set_arch_mach (&abfd, arch, 0); info.bfd_arch_info =3D bfd_get_arch_info (&abfd); mach =3D info.bfd_arch_info->mach; } This code change was necessary because the BFD architecture that was being = selected was 32-bit, which caused a wordsize mismatch and prevented GDB fro= m loading 64-bit executable files. The reason that I'm uncomfortable with the code change is that someone spec= ifically hard-coded the architecture and machine for xcoff executable files= , and I don't know why. I assume that there are at least some cases where = the BFD library doesn't set the architecture correctly for xcoff executable= s, but I'm not certain about that. It seems that the BFD library always se= ts the BFD architecture correctly for 64-bit executable files, though, so i= t seemed reasonable to have the code use the BFD architecture whenever the = wordsize is 8. Note: this is the only code change to gdb itself; the rest of the changes w= ere in the BFD library. Does anyone see any problem with this code change? Thanks, Dennis