gcc 4.7 libgo patch committed: Set libgo version number

[Ian Lance Taylor]

On Tue, Oct 23, 2012 at 12:37 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
>
> On Tue, 23 Oct 2012 06:55:01 +0200, Ian Lance Taylor wrote:
>> PR 54918 points out that libgo is not using version numbers as it
>> should.  At present none of libgo in 4.6, 4.7 and mainline are
>> compatible with each other.  This patch to the 4.7 branch sets the
>> version number for libgo there.  Bootstrapped and ran Go testsuite on
>> x86_64-unknown-linux-gnu.  Committed to 4.7 branch.
>
> it has regressed GDB testsuite:
>         -PASS: gdb.go/handcall.exp: print add (1, 2)
>         +FAIL: gdb.go/handcall.exp: print add (1, 2)
>
> GNU gdb (GDB) 7.5.50.20121022-cvs
>
> before:
> (gdb) print add (1, 2)
> $1 = 3
> (gdb) ptype add
> type = int32 (int, int)
> (gdb) info line add
> Line 219 of "../../../libgo/runtime/cpuprof.c" starts at address 0x7ffff55c0884 <tick+52> and ends at 0x7ffff55c0898 <tick+72>.
>
> now:
> (gdb) print add (1, 2)
> Too few arguments in function call.
> (gdb) ptype add
> type = void (Profile *, uintptr *, int32)
> (gdb) info line add
> Line 212 of "../../../gcc47/libgo/runtime/cpuprof.c" starts at address 0x7ffff55b05fe <add> and ends at 0x7ffff55b0609 <add+11>.

In both the before and after, gdb seems to be picking up the wrong
version of add, according to the line number information.  It's
picking up the static function add defined in the libgo library, not
the function defined in the user code.  The type information is
different but in fact the type of the static function in the libgo
library has not changed since it was introduced in March, 2011.  So
somehow in the before case gdb is displaying the line number of the
static function add but the type of the Go function add, but in the
after case gdb is displaying the line number and the type of the
static function.

I don't have any explanation for this difference but it's hard for me
to believe that the root cause is in libgo.  In effect there are two
functions named add: one is in libgo with C mangling, and one is in
the user code with Go mangling.  gdb is not picking the one that the
testsuite expects it to pick.

Ian