From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29918 invoked by alias); 9 Dec 2008 01:33:32 -0000 Received: (qmail 29909 invoked by uid 22791); 9 Dec 2008 01:33:31 -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; Tue, 09 Dec 2008 01:32:56 +0000 Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id mB91WstC030564 for ; Mon, 8 Dec 2008 17:32:54 -0800 Received: from localhost (elbrus.corp.google.com [172.18.116.17]) by wpaz24.hot.corp.google.com with ESMTP id mB91Wr3E010927 for ; Mon, 8 Dec 2008 17:32:53 -0800 Received: by localhost (Postfix, from userid 74925) id 9E1C83A6B2E; Mon, 8 Dec 2008 17:32:52 -0800 (PST) To: gdb-patches@sourceware.org Subject: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB. Message-Id: <20081209013252.9E1C83A6B2E@localhost> Date: Tue, 09 Dec 2008 01:33:00 -0000 From: ppluzhnikov@google.com (Paul Pluzhnikov) 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/msg00162.txt.bz2 Greetings, This came up while debugging one of my core files. The symptom is: GNU gdb (GDB) 6.8.50.20081209-cvs ... This GDB was configured as "x86_64-unknown-linux-gnu". ... Core was generated by `/tmp/a.out'. Program terminated with signal 11, Segmentation fault. [New process 7763] [New process 13974] [New process 7773] #0 chunk_alloc (ar_ptr=Cannot access memory at address 0xffffbf88 <<< What's that? ) at malloc.c:2896 2896 malloc.c: No such file or directory. in malloc.c (gdb) p ar_ptr Cannot access memory at address 0xffffbf88 32-bit gdb doesn't have a problem on the same core: Program terminated with signal 11, Segmentation fault. [New process 7763] [New process 13974] [New process 7773] #0 chunk_alloc (ar_ptr=0x1184f00, nb=10249) at malloc.c:2896 The problem is that in findvar.c: case LOC_ARG: if (frame == NULL) return 0; addr = get_frame_args_address (frame); if (!addr) return 0; addr += SYMBOL_VALUE (var); break; What happens if sizeof(addr) == 8 (64-bit gdb), len == 4 (32-bit target), get_frame_args_address() returns 0xffffbf98 (typical stack address) and SYMBOL_VALUE() returns -16? We end up with an impossible target address of 0x1ffffbf88. Attached patch fixes this. OK? -- Paul Pluzhnikov 2008-12-08 Paul Pluzhnikov * findvar.c (read_var_value): Truncate addr to target len. Index: findvar.c =================================================================== RCS file: /cvs/src/src/gdb/findvar.c,v retrieving revision 1.119 diff -u -p -u -r1.119 findvar.c --- findvar.c 2 Dec 2008 14:51:00 -0000 1.119 +++ findvar.c 9 Dec 2008 01:32:10 -0000 @@ -565,6 +565,10 @@ read_var_value (struct symbol *var, stru break; } + if (sizeof (addr) > len) + /* Truncate address to target length. */ + addr &= (1L << (8 * len)) - 1; + VALUE_ADDRESS (v) = addr; set_value_lazy (v, 1); return v;