http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583
--- Comment #5 from Uros Bizjak <ubizjak at gmail dot com> 2012-03-15 22:01:51
UTC ---
(In reply to comment #4)
> If you look at the test (libgo/go/log/log_test.go), you'll see that it simply
> does
>
> if useFormat {
> Printf("hello %d world", 23)
> } else {
> Println("hello", 23, "world")
> }
>
> This is calling log.Printf or log.Println. Those both wind up calling
> log.Output, which uses runtime.Caller to get a stack backtrace to their
> caller.
Right, the problem is triggered in line.go, line 111:
...
for _, ln := range u.lines {
>>> if pc < ln.addrs[0].pc || pc > ln.addrs[len(ln.addrs)-1].pc {
continue
}
...
The function is enter with pc:
(gdb) p/x *pc
$94 = 0x120005147
But ln.addrs ranges are set to:
(gdb) p ln.addrs
$95 = {__values = 0xf840002c00, __count = 17, __capacity = 32}
(gdb) p/x ln.addrs.__values[0].pc
$96 = 0x120004ca0
(gdb) p/x ln.addrs.__values[16].pc
$97 = 0x120004df4
However, the function is located at:
#8 0x0000000120005148 in log.testPrint (t=0xf840416d90, flag=<optimized out>,
prefix=..., pattern=..., useFormat=false) at log_test.go:45
45 Println("hello", 23, "world")
(gdb) disass
Dump of assembler code for function log.testPrint:
0x0000000120004ca0 <+0>: ldah gp,2(t12)
0x0000000120004ca4 <+4>: lda gp,-1912(gp)
0x0000000120004ca8 <+8>: ldq t12,-32456(gp)
0x0000000120004cac <+12>: lda sp,-432(sp)
...
0x0000000120005144 <+1188>: bsr ra,0x1200071c8
<libgo_log.log.Println+8>
=> 0x0000000120005148 <+1192>: unop
0x000000012000514c <+1196>: unop
0x0000000120005150 <+1200>: br 0x120004dd8 <log.testPrint+312>
0x0000000120005154 <+1204>: ldq t12,-32744(gp)
0x0000000120005158 <+1208>: lda a0,5
0x000000012000515c <+1212>: jsr ra,(t12),0x120005160
<log.testPrint+1216>
(line numbers are slightly changed due to my changes to log_test.go source for
debug purposes).
It looks that ln.addrs ranges are not correctly set. For some reason, line
numbers are truncated at line 48:
(gdb) p ln.addrs.__values[0].line
$100 = 37
(gdb) p ln.addrs.__values[16].line
$101 = 48
But the function in fact ends at line 58 in my case.
It just happens that the call to libgo_log.log.Printf lies inside (truncated)
ln.addrs[].pc ranges:
0x0000000120004dc8 <+296>: unop
0x0000000120004dcc <+300>: bsr ra,0x120007148 <libgo_log.log.Printf+8>
0x0000000120004dd0 <+304>: unop
0x0000000120004dd4 <+308>: unop
Any further help where to look for how ln.addrs ranges are determined?
