From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24609 invoked by alias); 14 Dec 2012 11:03:33 -0000 Received: (qmail 24600 invoked by uid 22791); 14 Dec 2012 11:03:32 -0000 X-SWARE-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BJ X-Spam-Check-By: sourceware.org Received: from mail-lb0-f169.google.com (HELO mail-lb0-f169.google.com) (209.85.217.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Dec 2012 11:03:26 +0000 Received: by mail-lb0-f169.google.com with SMTP id gk1so2663198lbb.0 for ; Fri, 14 Dec 2012 03:03:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.105.203 with SMTP id go11mr2179808lab.53.1355483005093; Fri, 14 Dec 2012 03:03:25 -0800 (PST) Received: by 10.112.32.1 with HTTP; Fri, 14 Dec 2012 03:03:24 -0800 (PST) In-Reply-To: <20121213151228.GA16752@host2.jankratochvil.net> References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F8FD047.6030702@codesourcery.com> <20121204141708.GA28600@host2.jankratochvil.net> <201212041444.qB4EiG4L025312@glazunov.sibelius.xs4all.nl> <20121204145144.GA30509@host2.jankratochvil.net> <50C1EE0B.3040905@codesourcery.com> <20121213151228.GA16752@host2.jankratochvil.net> Date: Fri, 14 Dec 2012 11:03:00 -0000 Message-ID: Subject: Re: Will therefore GDB utilize C++ or not? From: Matt Rice To: Jan Kratochvil Cc: Yao Qi , Mark Kettenis , gdb@sourceware.org, tromey@redhat.com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-12/txt/msg00055.txt.bz2 On Thu, Dec 13, 2012 at 7:12 AM, Jan Kratochvil wrote: > On Tue, 11 Dec 2012 07:25:33 +0100, Matt Rice wrote: >> On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi wrote: >> > How do you change the source tree? >> >> I create a git branch for each type of error message which gets >> rebased, > > could you provide some small preview of the work? > > I would like to prevent the case of 64-bit offsets were weeks/months of work > were invested to find in the end it is not well reviewable==usable. unfortunately I'm still trying to muster up motivation for this, I'll post a repository on gitorious when I do manage to get started since I don't want to litter the archer repo with a ton of branches. > On archer-ratmice-compile-Wc++-compat where the current trunk is > b68c4be8e0c1236639c6e5fc98c6894a746dde4e (from 2010) > I have found the last FSF GDB merge was from > e884cc5b62f170280dd49a35793bb516d95e7d8d > and while trying to /usr/bin/cmp a stripped binary (which does not match) > I have found this change: > > -void * > -grow_vect (void *vect, size_t *size, size_t min_size, int element_size) > +void > +grow_vect (gdb_byte **vect, size_t *size, size_t min_size, int element_size) > [...] > - vect = xrealloc (vect, *size * element_size); > + *vect = (gdb_byte *) xrealloc (*vect, *size * element_size); > } > - return vect; > } > > which while (probably) correct I find it outside of the scope of this branch, > making it more difficult to verify. This patch came from Joel Brobecker, after discussions on IRC about the GROW_VECT macro of ada-lang.h where we needed to add a cast to the (v) = grow_vect() call in the macro like: (v) (cast) = grow_vect(...). I believe my initial patch which I still have around added a cast argument to the macro (which requires updating all callers) similarly since we're now hard coding gdb_byte in the macro, we could also just hard code the cast in the macro without updating the grow_vect function, also forging updating callers (I don't believe it was called with anything but gdb_byte's in the first place). this really was the only place that had changes going beyond mundane. and since ada is his territory I just went with his patch, though I somewhat prefer adding the cast argument to the macro/updating callers as it keeps hard coded types out of otherwise generic code. I'd rather not do that if it means someone later wants to go back and deupdate all of the macro callers. > BTW I was using ad hoc > objdump -d --no-show-raw-insn gdb >1 > objdump -d --no-show-raw-insn gdb >2 > /usr/bin/diff -u [12] | vim - > and there > /^ .*\n .*\n .*\n .*\n .*\n .*\n > to find: > 72e351: mov -0x8(%rbp),%rax > - 72e355: mov (%rax),%rax > - 72e358: mov %rdx,%rsi > - 72e35b: mov %rax,%rdi > - 72e35e: callq 48ead0 > + 72e355: mov %rdx,%rsi > + 72e358: mov %rax,%rdi > + 72e35b: callq 48ead0 good to see that this picked up the change, and more importantly no others.