Re: Will therefore GDB utilize C++ or not?

[Matt Rice <ratmice at gmail dot com>]

On Thu, Dec 13, 2012 at 7:12 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 11 Dec 2012 07:25:33 +0100, Matt Rice wrote:
>> On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi <yao@codesourcery.com> 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 <xrealloc>
> +  72e355:      mov    %rdx,%rsi
> +  72e358:      mov    %rax,%rdi
> +  72e35b:      callq  48ead0 <xrealloc>

good to see that this picked up the change, and more importantly no others.