From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113802 invoked by alias); 5 Sep 2017 10:37:41 -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 113782 invoked by uid 89); 5 Sep 2017 10:37:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:sk:static., HContent-Transfer-Encoding:8bit X-HELO: mail-io0-f172.google.com Received: from mail-io0-f172.google.com (HELO mail-io0-f172.google.com) (209.85.223.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Sep 2017 10:37:35 +0000 Received: by mail-io0-f172.google.com with SMTP id z67so13915525iof.3 for ; Tue, 05 Sep 2017 03:37:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=UGBmF/aYAHhF7eXPgKdrrdTvUwg4Ogk79U7YT9NmcP4=; b=dvxzK0gEZh0ZbohdNIDIQt73mcuYHCEPOEnwwDZAbYtEIJwoRz/94UeffGkjPelY4V 4JjO4KD1YSO/ztN09zKa7Y+YpNcU21yDMfB5dcOCIU3tgJhUApMf0sV3s6fu42a1NGJB cXKE9r8LedVTVfOsxmjTvA0o3xA2N2ochsIFsv4gJw/ibZj1QqsWfSpQW84I6RA/pDjn 6NEEYATnbfKECbuEZfc5x5TC3l2kp1BR/K0jbKJ2U4+SKdo6eKAN3jnhdCULYCXgDfwm wKB1SJ8qMcW4cUtD6qcYs7M16oouJxocX6yk3IULMTAzCp8iG3AhlOwbihN92nklRbjo 199A== X-Gm-Message-State: AHPjjUhKTcatVEV4zgfeoLG++kz47Kzs3+UbqzfsPGdJ/ZwmzMmrtSgm hSB23E10PcwNIQ== X-Google-Smtp-Source: ADKCNb5PhA1w9iwELlLlj/QpRSIqr75WrtRMbR2cIzsZHowxLfpCzhAYl/9s4Y4No31K+VBGPvFF/A== X-Received: by 10.107.197.132 with SMTP id v126mr3299081iof.130.1504607854256; Tue, 05 Sep 2017 03:37:34 -0700 (PDT) Received: from 1170ee0b50d5 (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id f6sm115995ioa.12.2017.09.05.03.37.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 03:37:33 -0700 (PDT) Date: Tue, 05 Sep 2017 10:37:00 -0000 From: Yao Qi To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 3/4] Add thread after updating gdbarch when exec'ing Message-ID: <20170905103731.GF8425@1170ee0b50d5> References: <1503828934-26404-1-git-send-email-simon.marchi@ericsson.com> <1503828934-26404-4-git-send-email-simon.marchi@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1503828934-26404-4-git-send-email-simon.marchi@ericsson.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00083.txt.bz2 On 17-08-27 12:15:33, Simon Marchi wrote: > As mentioned in the previous patch, we should avoid doing register reads > after a process does an exec and before we've updated that inferior's > gdbarch. Otherwise, we may interpret the registers using the wrong > architecture. When a process does an exec with "follow-exec-mode new", > a new inferior is added by follow_exec. The gdbarch of that new > inferior is at first set to some default value, probably specific to the > gdb build (I get "i386" here), which may not be the right one. It is > updated later by the call to target_find_description. Before that > point, if we try to read the inferior's registers, we may not interpret > them correctly. This has been exposed by a failure in > gdb.base/foll-exec-mode.exp after the previous patch, with: > > Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes) > > The call to "add_thread" done just after adding the inferior is > problematic, because it ends up reading the registers (because the ptid > is re-used, we end up doing a switch_to_thread to it, which tries to > update stop_pc). The registers returned by gdbserver are the x86-64 > ones, while we try to interpret them using the "i386" gdbarch. The analysis is great! > > Postponing the call to add_thread to until the target > description/gdbarch has been updated seems to fix the issue. This imposes an odd restriction on using add_thread, that is, we must keep in mind that we can't use add_thread until the inferior's gdbarch or target description is updated. The question in my mind is that why do we need to update stop_pc in add_thread? or can we remove stop_pc? -- Yao (齐尧)