From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44033 invoked by alias); 23 Sep 2016 15:49: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 44023 invoked by uid 89); 23 Sep 2016 15:49:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:4.86_1, HCc:D*fr, H*F:U*tom, H*RU:cmgw2 X-HELO: gproxy9-pub.mail.unifiedlayer.com Received: from gproxy9-pub.mail.unifiedlayer.com (HELO gproxy9-pub.mail.unifiedlayer.com) (69.89.20.122) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Fri, 23 Sep 2016 15:49:37 +0000 Received: (qmail 29164 invoked by uid 0); 23 Sep 2016 15:49:34 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 23 Sep 2016 15:49:34 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw2 with id n3pT1t0172f2jeq013pW0R; Fri, 23 Sep 2016 09:49:33 -0600 X-Authority-Analysis: v=2.1 cv=F4vEKMRN c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=GW1xBdLrtEIA:10 a=20KFwNOVAAAA:8 a=KT85H_xs1V0z5ktw0yIA:9 a=e_O65bzb51kRm2y5VmPK:22 Received: from 174-16-151-161.hlrn.qwest.net ([174.16.151.161]:52924 helo=pokyo) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bnSjB-0007QW-9l; Fri, 23 Sep 2016 09:49:29 -0600 From: Tom Tromey To: Pedro Alves Cc: Pierre Muller , "'Tom Tromey'" , gdb-patches@sourceware.org Subject: Re: [RFA 3/5] Use std::string, std::vector in rust-lang.c References: <1474566656-15389-1-git-send-email-tom@tromey.com> <1474566656-15389-4-git-send-email-tom@tromey.com> <89b014ab-704c-bb8e-2e1a-6361efa5a644@redhat.com> <87bmzf21bf.fsf@tromey.com> <1b62c1c7-31ec-38c7-e4b4-25fdc560388c@redhat.com> <57e4328a.c3c4620a.59d5b.803fSMTPIN_ADDED_BROKEN@mx.google.com> <7ee42720-5b51-893e-b629-d39a573aa080@redhat.com> Date: Fri, 23 Sep 2016 15:56:00 -0000 In-Reply-To: <7ee42720-5b51-893e-b629-d39a573aa080@redhat.com> (Pedro Alves's message of "Fri, 23 Sep 2016 00:10:24 +0100") Message-ID: <8737kq1urb.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Exim-ID: 1bnSjB-0007QW-9l X-Source-Sender: 174-16-151-161.hlrn.qwest.net (pokyo) [174.16.151.161]:52924 X-Source-Auth: tom+tromey.com X-Email-Count: 5 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2016-09/txt/msg00308.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> There's a GNU extension that I think is meant to make it possible Pedro> for the debugger to treat uninitialized variables Pedro> specially (DW_OP_GNU_uninit), though I don't think we do Pedro> much with it. There were never any docs for it :( I think it probably should have been a piece-terminating operation but it was never clear if this was how it was actually supposed to work. I stuck a comment in dwarf_expr_require_composition to this effect back in the day. Pedro> Not sure gcc emits it, even. It does, but I don't know under what conditions. There's code in dwarf2out.c like: if (initialized == VAR_INIT_STATUS_UNINITIALIZED) add_loc_descr (&result, new_loc_descr (DW_OP_GNU_uninit, 0, 0)); I don't know when that happens though. Perhaps this could be cleaned up a bit, say by making DW_OP_GNU_uninit a piece terminator (I forget the official term here) and by changing gcc to emit a location list that indicates that the object is uninitialized until after the constructor is run. It might be a little friendlier to users, dunno. Tom