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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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