From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5706 invoked by alias); 28 Mar 2017 22:35:25 -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 5686 invoked by uid 89); 28 Mar 2017 22:35:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=crystal, !topic, vague, inquiry X-HELO: mail-wm0-f46.google.com Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Mar 2017 22:35:21 +0000 Received: by mail-wm0-f46.google.com with SMTP id x124so10603711wmf.0 for ; Tue, 28 Mar 2017 15:35:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ygAMLXYmO/6+YJJznZLfwZxgoWhrVVfZyHQybGDzWpc=; b=nleyggSkLQVGThMwCk/U7fDnVxdpBdr01sL+2MLt3yPb70EaxJXQvFKywzuYGjThBO QlCzNJFdni+gcgqXR7f71Tg2BHEC+gztxInyLKYJ8+dWHoHUibV6IZS1Idn7ztEIZHdR FE60B7YPRbWhBQukFHhl3grB6zWttkH7aA0SPoFx2+xpkmYwkv01B9N6QtBa7hQAd7VO deZWD3Y0xsJeo5BSMltM8qzGpg8yK1UL5/maJgPhBXKk/4jWvRukanKLGMcI14SQ6iBf OeYIjlTacMbIYxcmHkywmQCcVv75o+o7tSYMPR8Fge+0UF+W4v0VC2XqCyvisJsvLD8B aWOw== X-Gm-Message-State: AFeK/H3mqpUS49erlME21E8atycPl1eXukPreAsL8P1t+6l/6aIbMldJh0s9b1yKp6txWEYq X-Received: by 10.28.7.13 with SMTP id 13mr16457856wmh.16.1490740520941; Tue, 28 Mar 2017 15:35:20 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id x133sm5276658wme.22.2017.03.28.15.35.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 15:35:20 -0700 (PDT) Subject: Re: [PATCH 1/2] Add constructor and destructor to thread_info To: Yao Qi References: <1490689483-16084-1-git-send-email-yao.qi@linaro.org> <1490689483-16084-2-git-send-email-yao.qi@linaro.org> <06385391-127e-87b7-d727-7d03a23f293c@redhat.com> <86inmto5nx.fsf@gmail.com> <86efxho1f2.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <577b5d2b-a122-5318-745e-3d19843a5ea4@redhat.com> Date: Tue, 28 Mar 2017 22:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <86efxho1f2.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00492.txt.bz2 On 03/28/2017 04:40 PM, Yao Qi wrote: > Pedro Alves writes: > >>>> - struct target_waitstatus pending_follow; >>>> + struct target_waitstatus pending_follow {TARGET_WAITKIND_SPURIOUS}; >>>> >>> >>> This will only initialize the first member of union >>> target_waitstatus.value to zero, so some bits of >>> target_waitstatus.value.related_pid is not initialized. >> >> Ah, blah, unions. Well, the result is that the remaining fields of >> the struct end up list->value->zero-initialized. Zero-initialization >> for unions means the first member is zero-initialized, and padding >> is initialized to zero. So I think the end result is the >> same anyway. > > It is different from > "memset (&this->pending_follow, 0, sizeof (this->pending_follow))". The > first member "integer" is zero-initialized, but it is not the largest > member, so part of "related_pid" is not zero-initialized. > > |<------------------ union----------------->| > |<------- related_pid ------->|<- padding ->| > |<- integer ->| > | 0 || 0 | > I'm not so sure about that. That is not my interpretation, though the standard isn't crystal clear here. The definition of "padding" is left vague. It doesn't look like that's the interpretation of either G++ nor Clang though. G++ always zeroes the whole object, while Clang initializes only the first member, leaving everything else uninitialized, which I found surprising, since no padding _at all_ of any kind is initialized then. I've sent an inquiry to std-discussion at isocpp.org list earlier today, though I haven't gotten an answer yet. See: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/ljaMNnkahHA Though given Clang's behavior, it's probably not a good idea to assume everything's zeroed out. target_waitstatus would be a natural fit for something like C++17's std::variant. Particularly, the lifetime of value.execd_pathname is not well defined... Let's go with what you had, and revisit if/when we change/fix target_waitstatus. Thanks, Pedro Alves