From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73129 invoked by alias); 30 Mar 2016 15:17:18 -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 73111 invoked by uid 89); 30 Mar 2016 15:17:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2146, H*F:D*ericsson.com, agent, par X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 30 Mar 2016 15:17:07 +0000 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 5D.15.30335.318EBF65; Wed, 30 Mar 2016 16:52:03 +0200 (CEST) Received: from elxcz23q12-y4.dyn.mo.ca.am.ericsson.se (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.96) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 30 Mar 2016 11:17:04 -0400 From: Simon Marchi To: CC: Par Olsson Subject: [PATCH 1/2] Fix write endianness/size problem for fast tracepoint enabled flag Date: Wed, 30 Mar 2016 15:17:00 -0000 Message-ID: <1459351018-23718-1-git-send-email-simon.marchi@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00570.txt.bz2 From: Par Olsson I am sending this fix on behalf of Par Olsson, as a follow-up of this one: https://www.sourceware.org/ml/gdb-patches/2015-10/msg00196.html This problem is exposed when enabling/disabling fast tracepoints on big endian machines. The flag is defined as an int8_t, but is written from gdbserver as an integer (usually 32 bits). When the agent code reads it as an int8_t, it only considers the most significant byte, which is always 0. Also, we were writing 32 bits in an 8 bits field, so the write would overflow, but since the following bytes are padding (the next field is an uint64_t), it luckily didn't cause any issue on little endian systems. The fix was originally tested on ARM big endian systems, but I don't have access to such a system. However, thanks to Marcin's PowerPC fast tracepoint patches and gcc110 (big endian Power7) on the gcc compile farm, I was able to reproduce the problem, test the fix and write a test (the following patch). gdb/gdbserver/ChangeLog: YYYY-MM-DD Par Olsson * tracepoint.c (write_inferior_int8): New function. (cmd_qtenable_disable): Write enable flag using write_inferior_int8. --- gdb/gdbserver/tracepoint.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/gdb/gdbserver/tracepoint.c b/gdb/gdbserver/tracepoint.c index 7c20612..3e0d57a 100644 --- a/gdb/gdbserver/tracepoint.c +++ b/gdb/gdbserver/tracepoint.c @@ -449,6 +449,12 @@ write_inferior_integer (CORE_ADDR symaddr, int val) } static int +write_inferior_int8 (CORE_ADDR symaddr, int8_t val) +{ + return write_inferior_memory (symaddr, (unsigned char *) &val, sizeof (val)); +} + +static int write_inferior_uinteger (CORE_ADDR symaddr, unsigned int val) { return write_inferior_memory (symaddr, (unsigned char *) &val, sizeof (val)); @@ -2784,7 +2790,7 @@ cmd_qtenable_disable (char *own_buf, int enable) return; } - ret = write_inferior_integer (obj_addr, enable); + ret = write_inferior_int8 (obj_addr, enable); done_accessing_memory (); if (ret) -- 2.8.0