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

Jan Kratochvil
2012-12-13T15:12:47Z

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.

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.

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>

Thanks,
Jan