From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6396 invoked by alias); 1 Dec 2009 12:02:02 -0000 Received: (qmail 6259 invoked by uid 22791); 1 Dec 2009 12:02:01 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Dec 2009 12:01:53 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB1C1q6W022381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Dec 2009 07:01:52 -0500 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nB1C1okx027931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Dec 2009 07:01:51 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id nB1C1n6p005918; Tue, 1 Dec 2009 13:01:49 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id nB1C1nwj005917; Tue, 1 Dec 2009 13:01:49 +0100 Date: Tue, 01 Dec 2009 12:02:00 -0000 From: Jan Kratochvil To: paawan oza Cc: gdb@sourceware.org Subject: Re: 32 bit applcaition debugging with 64bit gdb on 64bit machine Message-ID: <20091201120148.GA4517@host0.dyn.jankratochvil.net> References: <33317.35316.qm@web112515.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33317.35316.qm@web112515.mail.gq1.yahoo.com> User-Agent: Mutt/1.5.20 (2009-08-17) 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: 2009-12/txt/msg00004.txt.bz2 On Tue, 01 Dec 2009 10:15:47 +0100, paawan oza wrote: > I have following questions, please try to clarify. > > I compile gdb on 64 bit machine, > > 1) 32 bit application compiled on 32 bit system and directly using them on 64 bit machine, and then we debug the 32 bit application using 64 bit gdb on 64 bit machine. > > 2) 32 bit applications compiled on 64 bit machine using -m32 flag, and then I try to compile 32 bit application using 64 bit gdb in 64 bit machine. > > 3) of course 64bit applications must be able to be debugged easily by 64 bit gdb on 64 bit machine. > > In 1 and 2, is there any case where gdb may not work or may have some issue ? > I suppose 3 must not have any issue. build: Differences between native 32bit build and -m32 build on 64bit should be none as (a) the gcc target code is the same and (b) the 32bit libraries are exactly the same binary on 64bit hosts (at least on FedorA). debugging: All the cases should work and they are +/- supported for debugging: kernel debugger inferior x86_64 x86_64 x86_64 = native 64bit x86_64 x86_64 i386 x86_64 i386 i386 i386 i386 i386 = native 32bit But there are occasional GDB bugs such as: [patch] Fix syscall restarts for amd64->i386 biarch http://sourceware.org/ml/gdb-patches/2009-11/msg00592.html [patch 03/15] PIE: breakpoint_address_match gdbarch_addr_bit workaround http://sourceware.org/ml/gdb-patches/2009-11/msg00170.html (while this case is required only for the still non-upstreamed PIE patch I guess one could find similar bug in existing code) [checked-in] [patch] Fix i386 memory-by-register access on amd64 http://sourceware.org/ml/gdb-patches/2009-04/msg00786.html [not upstreamed] [patch] Support gcore for i386 inferiors on amd64 http://sourceware.org/ml/gdb-patches/2006-09/msg00159.html http://cvs.fedora.redhat.com/viewvc/rpms/gdb/F-12/gdb-6.5-gcore-i386-on-amd64.patch?content-type=text%2Fplain&view=co Linux kernels had various problems running both the x86_64-x86_64-i386 and x86_64-i386-i386 cases (the same for ppc*; for example s390x-s390-s390 is officailly not supported). Various such bugs were found/fixed, this is why biarch-tests/ build (erestartsys-trap was failing only in biarch mode recently) and -debugge{r,e} testcases exist there: http://sourceware.org/systemtap/wiki/utrace/tests One should run the two biarch modes (-m32 build of gdb and check//unix/-m32 testsuite run with 64bit gdb) and check the gdb testsuite produces exactly the same results as on native 32bit host/kernel. I was doing these comparisons in the past which were a source for some bugreports+fixes above and others. I do not run these tests regularly, one should recheck it. vDSO: Linux kernel provides [vdso] 4KB page which intentionally uses some instructions not present on 32bit native targets which may cause some incompatibilities for 32-bit era debuggers not ready for them: Vitaly Mayatskikh: I can confirm, this is internal kernel issue in arch/x86_64/ia32/syscall32.c. It reproducible on every AMD machine, because kernel uses `sysenter' for Intel machines and `syscall' instead of `int80' otherwise. Seems, AMD is able to execute `syscall' from compatibility mode and this is faster than `int80'. Isn't it cheaper to fix gdb and not to loose cpu time for every system call in ia32 emulation mode? IIRC, on Intel machines `syscall' costs approx. 1200 tacts and `int80' approx 2500. Regards, Jan