From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4683 invoked by alias); 13 Dec 2008 18:18:23 -0000 Received: (qmail 4675 invoked by uid 22791); 13 Dec 2008 18:18:22 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Dec 2008 18:17:47 +0000 Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id mBDIHiov028290 for ; Sat, 13 Dec 2008 10:17:44 -0800 Received: from ey-out-1920.google.com (eyg4.prod.google.com [10.208.7.4]) by wpaz5.hot.corp.google.com with ESMTP id mBDIHgMN018828 for ; Sat, 13 Dec 2008 10:17:43 -0800 Received: by ey-out-1920.google.com with SMTP id 4so260748eyg.24 for ; Sat, 13 Dec 2008 10:17:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.210.59.3 with SMTP id h3mr5697082eba.87.1229192262242; Sat, 13 Dec 2008 10:17:42 -0800 (PST) In-Reply-To: <20081213160110.GF6866@adacore.com> References: <20081209013252.9E1C83A6B2E@localhost> <8ac60eac0812081842l6ac5344fw2fd57011d3dfef42@mail.gmail.com> <20081209133408.GA16288@caradoc.them.org> <20081210111322.GC20054@adacore.com> <8ac60eac0812100758i586c66eak533680a6eb07459c@mail.gmail.com> <8ac60eac0812101520x76366795ieea6afb6d48fb129@mail.gmail.com> <8ac60eac0812111601v20566268h6f7977c71e5b8a8f@mail.gmail.com> <8ac60eac0812111603r68ffa49exd7cb0ce403d07310@mail.gmail.com> <20081213160110.GF6866@adacore.com> Date: Sat, 13 Dec 2008 18:18:00 -0000 Message-ID: <8ac60eac0812131017l6eec4bf9r1a9fedf3e68bc6bb@mail.gmail.com> Subject: Re: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB. From: Paul Pluzhnikov To: Joel Brobecker Cc: Andreas Schwab , gdb-patches@sourceware.org Content-Type: multipart/mixed; boundary=0015174bf1f426d184045df1a073 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00246.txt.bz2 --0015174bf1f426d184045df1a073 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 1692 On Sat, Dec 13, 2008 at 8:01 AM, Joel Brobecker wrote: > > - leave GDB broken and wait for newer glibc :( > > I'm just realizing that this might be a very very visible problem, > if most offsets are negative. Is that the case? Now that you've mentioned it, I see that there is a trivial test case: int bar(int x) { return x; } int foo(int x) { int y = x; return bar(y); } int main() { return foo(0); } gcc -gstabs -m32 t.c && gdb64 -q ./a.out (gdb) b bar Breakpoint 1 at 0x8048303: file t.c, line 1. (gdb) r Breakpoint 1, bar (x=0) at t.c:1 1 int bar(int x) { return x; } (gdb) up #1 0x0804831f in foo (x=0) at t.c:2 2 int foo(int x) { int y = x; return bar(y); } (gdb) info locals y = Cannot access memory at address 0xffffd954 > > - do sign extension, but only for N_LSYM and N_PSYM symbols as > > a heuristic. > > It seems to me that this should work without negative effect > (we have to be a little careful because there is a 64bit stabs > extension on Tru64). AFAICT, Tru64 goes through ECOFF reader in mdebugread.c, and so wouldn't be affected by a change to dbxread.c > After all, values for these types of symbols > are always offsets to some location inside a frame, and I can't see > a frame being that big. Especially in a 32-bit executable ... > > - pre-scan the objfile to determine highest link address, and > > do sign extension if that address is (well) below 0x80000000 > > Seems too much work, IMO. Right. So here is a 3rd attempt. Thanks, -- Paul Pluzhnikov 2008-12-12 Paul Pluzhnikov * dbxread.c (read_ofile_symtab): Sign-extend 32-bit N_LSYM and N_PSYM STABS values for 64-bit GDB. --0015174bf1f426d184045df1a073 Content-Type: text/plain; charset=US-ASCII; name="gdb-1526195-20081212.txt" Content-Disposition: attachment; filename="gdb-1526195-20081212.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fool4rl10 Content-length: 981 SW5kZXg6IGRieHJlYWQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBm aWxlOiAvY3ZzL3NyYy9zcmMvZ2RiL2RieHJlYWQuYyx2CnJldHJpZXZpbmcg cmV2aXNpb24gMS45OApkaWZmIC11IC1wIC11IC1yMS45OCBkYnhyZWFkLmMK LS0tIGRieHJlYWQuYwkxIE9jdCAyMDA4IDE2OjQxOjI3IC0wMDAwCTEuOTgK KysrIGRieHJlYWQuYwkxMyBEZWMgMjAwOCAxODowNzozMSAtMDAwMApAQCAt MjU5Nyw2ICsyNTk3LDExIEBAIHJlYWRfb2ZpbGVfc3ltdGFiIChzdHJ1Y3Qg cGFydGlhbF9zeW10YWIKIAogICAgICAgaWYgKHR5cGUgJiBOX1NUQUIpCiAJ eworCSAgaWYgKHNpemVvZiAobmxpc3Qubl92YWx1ZSkgPiA0CisJICAgICAg JiYgKHR5cGUgPT0gTl9MU1lNIHx8IHR5cGUgPT0gTl9QU1lNKSkKKwkgICAg LyogVGhlc2UgYXJlIHZlcnkgbGlrZWx5IHRvIGJlIDMyLWJpdCBuZWdhdGl2 ZS4KKwkgICAgICAgU2lnbi1leHRlbmQgdGhlbSBmb3IgNjQtYml0IEdEQi4g ICovCisJICAgIG5saXN0Lm5fdmFsdWUgPSAobmxpc3Qubl92YWx1ZSBeIDB4 ODAwMDAwMDApIC0gMHg4MDAwMDAwMDsKIAkgIHByb2Nlc3Nfb25lX3N5bWJv bCAodHlwZSwgbmxpc3Qubl9kZXNjLCBubGlzdC5uX3ZhbHVlLAogCQkJICAg ICAgbmFtZXN0cmluZywgc2VjdGlvbl9vZmZzZXRzLCBvYmpmaWxlKTsKIAl9 Cg== --0015174bf1f426d184045df1a073--