From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22133 invoked by alias); 25 May 2013 01:25:48 -0000 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 Received: (qmail 22123 invoked by uid 89); 25 May 2013 01:25:47 -0000 X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_PASS,TW_VF autolearn=ham version=3.3.1 Received: from mail-qc0-f201.google.com (HELO mail-qc0-f201.google.com) (209.85.216.201) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 25 May 2013 01:25:46 +0000 Received: by mail-qc0-f201.google.com with SMTP id j10so564565qcx.4 for ; Fri, 24 May 2013 18:25:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:message-id:from:to:subject:x-gm-message-state; bh=LNLT3aJC5JCTegFGn8YrIEngmafneJa+l/FudIjVvzU=; b=FttujwOVcMAT+Pkkr6BmUBccLsIyD7vrzAUzhhrUAuO1te+r5REIBG1qlgLY8nB0RA E2ETAJfozfqwno2BNhadAVcdSYRdXvDjIizrW6DFmxP72NjHg8G8n+uSWsopcOKx4X+b H9HefrDLsJz1HXBqTZr2XZa2ZD6Iy8i3GL5brpGQi8fj5CF8v9eyG+nQm4EHzLjul5H+ EJObe2B31vl+ltPmE1fNCz4YFFnCkdlUXswa0OX/JXVDxwmd83h3BGtsRhNkIkHyvh7W aP3xmfwQqGtxj+KZW5/og1aqnAHgEhHcOL4qglYcArKceP3jWIUYvzzVrnvazK3NGpG5 H0xA== X-Received: by 10.236.46.50 with SMTP id q38mr9234577yhb.44.1369445145127; Fri, 24 May 2013 18:25:45 -0700 (PDT) Received: from corp2gmr1-1.hot.corp.google.com (corp2gmr1-1.hot.corp.google.com [172.24.189.92]) by gmr-mx.google.com with ESMTPS id k33si1495844yhi.3.2013.05.24.18.25.45 for (version=TLSv1.1 cipher=AES128-SHA bits=128/128); Fri, 24 May 2013 18:25:45 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com (ruffy2.mtv.corp.google.com [172.17.128.107]) by corp2gmr1-1.hot.corp.google.com (Postfix) with ESMTP id BC53331C022 for ; Fri, 24 May 2013 18:25:44 -0700 (PDT) Date: Sat, 25 May 2013 01:25:00 -0000 Message-Id: From: Doug Evans To: gdb-patches@sourceware.org Subject: [patch] Fix 64x32 handling in gdbserver/linux-x86-low.c:ps_get_thread_area X-Gm-Message-State: ALoCoQlxBpsWb+BzdTRT1712MACF6hK6l4DRi/0QNGtzSDYdlEW70ymDYpzE0eB8wX34f4kC+buhLWWx6w5IFIG7CvKHtAxXqM/ESWT6PKWe5pahJHbj/GiKilGjUYxwNntpI2LfJiKP/sUzbf0B6927P4SbU6zIS2bO1MP7Q64EOncmPS2O0dppPZcYr0EbezbtNxvanJmrsDcVZO4A2NB9kuyJM49uCLq1ZxzOuiXMDStjlVICL3E= X-SW-Source: 2013-05/txt/msg00936.txt.bz2 Hi. I found this while testing gdbserver with 64x32 (64-bit gdb/gdbserver with the testcase compiled for 32-bit). tls.exp has a number of bizarre failures. E.g., Cannot find thread-local storage for Thread 16598, executable file /g5/local/ctools/gdb/trunk/build/obj64/gdb/testsuite/gdb.threads/tls: and gdbserver: PID mismatch! Expected 16598, got 16596 I found the cause to be the storing of a 32 bit address in a 64 bit value, leaving the high bits uninitialized. One can see the bug with this patch. diff thread-db.c --- thread-db.c~ 2013-02-19 14:45:14.000000000 -0800 +++ thread-db.c 2013-05-24 17:20:14.450500768 -0700 @@ -40,6 +40,8 @@ #include #endif +#include +#include #include #include #include @@ -267,6 +269,22 @@ return 1; } +void +plogf (const char *msg, ...) +{ + static FILE *f; + va_list args; + if (f == NULL) + { + f = fopen ("/tmp/gdbserver.log", "a"); + fprintf (f, "... new run ...\n"); + } + va_start (args, msg); + vfprintf (f, msg, args); + va_end (args); + fflush (f); +} + static int find_one_thread (ptid_t ptid) { @@ -283,12 +301,18 @@ if (lwp->thread_known) return 1; + memset (&th, -1, sizeof (th)); + /* Get information about this thread. */ err = thread_db->td_ta_map_lwp2thr_p (thread_db->thread_agent, lwpid, &th); if (err != TD_OK) error ("Cannot get thread handle for LWP %d: %s", lwpid, thread_db_err_str (err)); + plogf ("lwpid %d\n", lwpid); + plogf ("th_ta_p %p\n", th.th_ta_p); + plogf ("th_unique %p\n", th.th_unique); + err = thread_db->td_thr_get_info_p (&th, &ti); if (err != TD_OK) error ("Cannot get thread info for LWP %d: %s", --- Testing tls.exp in 32-bit mode with 64-bit gdb/gdbserver, one sees this in /tmp/gdbserver.log: ... new run ... lwpid 16596 th_ta_p 0x17ce020 th_unique (nil) lwpid 16598 th_ta_p 0x17ce020 th_unique 0xfffffffff7cb9b40 lwpid 16598 th_ta_p 0x17ce020 th_unique 0xfffffffff7cb9b40 ... I need to do a bit more testing, but this seems pretty obvious. The bug doesn't exist in gdb, it already does the needed extension. 2013-05-24 Doug Evans * linux-x86-low.c (ps_get_thread_area): Properly extend address to 64 bits in 64-cross-32 environment. Index: gdbserver/linux-x86-low.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/linux-x86-low.c,v retrieving revision 1.45 diff -u -p -r1.45 linux-x86-low.c --- gdbserver/linux-x86-low.c 23 May 2013 17:17:50 -0000 1.45 +++ gdbserver/linux-x86-low.c 25 May 2013 01:06:49 -0000 @@ -196,7 +196,8 @@ ps_get_thread_area (const struct ps_proc (void *) (intptr_t) idx, (unsigned long) &desc) < 0) return PS_ERR; - *(int *)base = desc[1]; + /* Ensure we properly extend the value to 64-bits for x86_64. */ + *base = (void*) (uintptr_t) desc[1]; return PS_OK; } }