From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25344 invoked by alias); 18 Apr 2017 18:49:06 -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 25332 invoked by uid 89); 18 Apr 2017 18:49:06 -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,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Apr 2017 18:49:04 +0000 Received: by simark.ca (Postfix, from userid 33) id 39AF81E48B; Tue, 18 Apr 2017 14:49:04 -0400 (EDT) To: Andreas Arnez Subject: Re: [PATCH 4/9] Remove addr_size field from struct piece_closure X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Apr 2017 18:49:00 -0000 From: Simon Marchi Cc: Yao Qi , gdb-patches@sourceware.org In-Reply-To: References: <1491586736-21296-1-git-send-email-arnez@linux.vnet.ibm.com> <1491586736-21296-5-git-send-email-arnez@linux.vnet.ibm.com> <86inm8ad1y.fsf@gmail.com> <6fef62cbc51a5ff8f23b92612cf267ac@polymtl.ca> Message-ID: <6fb430376b088892e4591976372a55d5@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.4 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00525.txt.bz2 On 2017-04-18 13:24, Andreas Arnez wrote: >> Since you are planning on making a v2, I think it's better if you >> check it >> in right now to get it out of the way (it could be obvious anyway). > > I would, but it depends on the patch before -- "[PATCH 3/9] PR > gdb/21226: Take DWARF stack value pieces from LSB end". > > (Maybe it wasn't clear, but the current code for handling DWARF stack > values is slightly more broken than just not taking them from the > correct end. It also uses the relic "addr_size" instead of the actual > DWARF stack value size to determine whether the piece is contained in > its underlying object. And if it's *partially* contained, like taking > a > 1MB piece from a 64-bit stack value, the current code accesses invalid > memory anyway.) Ah yes indeed, my bad.