Re: earmhf issues on Beaglebone Black

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Jul 22, 2014 at 01:17:29PM +0200, Manuel Bouyer wrote:
> On Mon, Jul 21, 2014 at 10:52:45PM +0200, Manuel Bouyer wrote:
> > [...]
> > Here's a kdump related to one of these messages:
> >    773      1 make     CALL  pipe
> >    773      1 make     RET   pipe 3, 4
> >    773      1 make     CALL  getpid
> >    773      1 make     RET   getpid 773/0x305, 1223/0x4c7
> >    773      1 make     CALL  __vfork14
> >     85      1 make     EMUL  "netbsd"
> >     85      1 make     RET   fork 0
> >     85      1 make     CALL  close(3)
> >     85      1 make     RET   close 0
> >     85      1 make     CALL  dup2(4,1)
> >     85      1 make     RET   dup2 1
> >     85      1 make     CALL  close(4)
> >     85      1 make     RET   close 0
> >     85      1 make     CALL  execve(0x403124d0,0x7fffb6e8,0x7fffcb90)
> >     85      1 make     NAMI  "/bin/sh"
> >     85      1 make     NAMI  "/libexec/ld.elf_so"
> >    773      1 make     RET   __vfork14 85/0x55
> >    773      1 make     CALL  close(4)
> >    773      1 make     RET   close 0
> >    773      1 make     CALL  read(3,0x7fffb6f8,0x400)
> >    773      1 make     GIO   fd 3 read 0 bytes
> >        ""
> >    773      1 make     RET   read 0
> >    773      1 make     CALL  close(3)
> >    773      1 make     RET   close 0
> >    773      1 make     CALL  __wait450(0x55,0x7fffb6f8,0,0)
> >    773      1 make     RET   __wait450 85/0x55
> >    773      1 make     CALL  write(2,0x7fffb618,9)
> >    773      1 make     GIO   fd 2 wrote 9 bytes
> >        "make[3]: "
> >    773      1 make     RET   write 9
> >    773      1 make     CALL  write(2,0x465ab,1)
> >    773      1 make     GIO   fd 2 wrote 1 bytes
> >        "\""
> >    773      1 make     RET   write 1
> >    773      1 make     CALL  write(2,0x7fffb618,0x2a)
> >    773      1 make     GIO   fd 2 wrote 42 bytes
> >        "../../mk/compiler/../../mk/compiler/gcc.mk"
> >    773      1 make     RET   write 42/0x2a
> >    773      1 make     CALL  write(2,0x7fffb618,0xc)
> >    773      1 make     GIO   fd 2 wrote 12 bytes
> >        "\" line 168: "
> >    773      1 make     RET   write 12/0xc
> >    773      1 make     CALL  write(2,0x3144c,9)
> >    773      1 make     GIO   fd 2 wrote 9 bytes
> >        "warning: "
> >    773      1 make     RET   write 9
> >    773      1 make     CALL  write(2,0x7fffb648,0x6d)
> >    773      1 make     GIO   fd 2 wrote 109 bytes
> >        "\"( env LC_ALL=C /usr/bin/gcc -v 2>&1 | /usr/bin/grep 'gcc 
> > version') 2\
> >         >/dev/null || echo 0\" exited on a signal"
> >    773      1 make     RET   write 109/0x6d
> > 
> > Maybe it's related to vfork ?
> 
> Here's a "normal" vfork sequence from make:
>     35      1 make     CALL  __vfork14
>     34      1 make     EMUL  "netbsd"
>     34      1 make     RET   fork 0
>     34      1 make     CALL  execve(0x7fffb9cc,0x4034e050,0x40310100)
>     34      1 make     NAMI  "/sbin/cc"
>     34      1 make     RET   execve -1 errno 2 No such file or directory
>     34      1 make     CALL  execve(0x7fffb9cc,0x4034e050,0x40310100)
>     34      1 make     NAMI  "/usr/sbin/cc"
>     34      1 make     RET   execve -1 errno 2 No such file or directory
>     34      1 make     CALL  execve(0x7fffb9cc,0x4034e050,0x40310100)
>     34      1 make     NAMI  "/bin/cc"
>     34      1 make     RET   execve -1 errno 2 No such file or directory
>     34      1 make     CALL  execve(0x7fffb9cc,0x4034e050,0x40310100)
>     34      1 make     NAMI  "/usr/bin/cc"
>     34      1 make     NAMI  "/usr/libexec/ld.elf_so"
>     34      1 cc       EMUL  "netbsd"
>     34      1 cc       RET   execve JUSTRETURN
>     35      1 make     RET   __vfork14 34/0x22
>     35      1 make     CALL  __wait450(0xffffffff,0x7fffbe1c,0,0)
>     34      1 cc       CALL  mmap(0,0x8000,3,0x1002,0xffffffff,0,0,0)
>     34      1 cc       RET   mmap 1074544640/0x400c4000
>     34      1 cc       CALL  open(0x400ae5b8,0,0x400c2648)
> 
> So it looks like the fault happens inside the execve(), but before the
> new executable has actually been loaded (which could explain
> why there's no core dump). 

I added a Debugger() call just after the "data_aborts fsr=" printf:
data_abort_handler: data_aborts fsr=0x180e far=0x7fffcb58
Stopped in pid 5484.1 (sh) at   netbsd:cpu_Debugger+0x4:        bx      r14
db> tr
0x9f935b8c: netbsd:data_abort_handler+0xc
db> tr/t 0t5484
trace: pid 5484 lid 1 at 0x9f935a5c
0x9f935a5c: 9f935a68
(2822 is the parent):
db> tr/a 9faf53a0
trace: pid 2822 lid 1 at 0x9f9f1df4
0x9f9f1df4: netbsd:mi_switch+0x10
0x9f9f1e24: netbsd:sleepq_block+0xa8
0x9f9f1e54: netbsd:cv_wait+0xf8
0x9f9f1ee4: netbsd:fork1+0x60c
0x9f9f1f0c: netbsd:sys___vfork14+0x38
0x9f9f1f7c: netbsd:syscall+0x84
0x9f9f1fac: netbsd:swi_handler+0x98

I expected to get some more usefull informations, unfortunably it was not
the case.
Is 0x9f935a5c really a kernel address ? gdb doens't know about it,
and netbsd.map shows kernel text is in 0x80300000 - 0x80555a78.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--