On Tue, Oct 23, 2012 at 12:37 AM, Jan Kratochvil <jan.kratoch...@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