John David Anglin wrote:
>> Could you run the entire build with LD_BIND_NOW=3D1 set? Does it crash
>> anywhere else?
>
> Got a lot further but bash SEGV'd again:
>
> Program terminated with signal 11, Segmentation fault.
> [New process 14746]
> #0 0x00035ba4 in close_fd_bitmap ()
> (gdb) bt
> #0 0x00035ba4 in close_fd_bitmap ()
> #1 0x00039d08 in ?? ()
> #2 0x000373b8 in execute_command_internal ()
> #3 0x00036d3c in ?? ()
> #4 0x000382a4 in execute_command_internal ()
> #5 0x00073a68 in parse_and_execute ()
> #6 0x0004d840 in command_substitute ()
> #7 0x00051e14 in ?? ()
> #8 0x00053320 in ?? ()
> #9 0x00056fa8 in expand_string_assignment ()
> #10 0x00050f44 in ?? ()
> #11 0x000512fc in ?? ()
> #12 0x00053278 in ?? ()
> #13 0x0003a0a4 in ?? ()
> #14 0x000373b8 in execute_command_internal ()
> #15 0x00038638 in execute_command ()
> #16 0x00038310 in execute_command_internal ()
> #17 0x00073a68 in parse_and_execute ()
> #18 0x00025a1c in ?? ()
> #19 0x000269a8 in main ()
>
> Restarting, and it crashed again:
>
> Core was generated by `/bin/sh ./libtool --tag=CXX --mode=compile /home/dave/gnu/gcc/objdir/./gcc/xgcc'.
> Program terminated with signal 11, Segmentation fault.
> [New process 32486]
> #0 0x00000000 in ?? ()
> (gdb) bt
> #0 0x00000000 in ?? ()
> #1 0x000ab3dc in ?? ()
> #2 0x0006e930 in sh_xmalloc ()
> #3 0x0004995c in stop_pipeline ()
> #4 0x00037cec in execute_command_internal ()
> #5 0x00038638 in execute_command ()
> #6 0x00038310 in execute_command_internal ()
> #7 0x00037a60 in execute_command_internal ()
> #8 0x00038638 in execute_command ()
> #9 0x000374c4 in execute_command_internal ()
> #10 0x00037a60 in execute_command_internal ()
> #11 0x00037a60 in execute_command_internal ()
> #12 0x000395f8 in ?? ()
> #13 0x0003a85c in ?? ()
> #14 0x000373b8 in execute_command_internal ()
> #15 0x00038638 in execute_command ()
> #16 0x00038310 in execute_command_internal ()
> #17 0x00037a60 in execute_command_internal ()
> #18 0x00038638 in execute_command ()
> #19 0x000374c4 in execute_command_internal ()
> #20 0x00037a60 in execute_command_internal ()
> #21 0x00038638 in execute_command ()
> #22 0x00038310 in execute_command_internal ()
> ---Type <return> to continue, or q <return> to quit---
> #23 0x00037a60 in execute_command_internal ()
> #24 0x000395f8 in ?? ()
> #25 0x0003a85c in ?? ()
> #26 0x000373b8 in execute_command_internal ()
> #27 0x00038638 in execute_command ()
> #28 0x000374c4 in execute_command_internal ()
> #29 0x00037a60 in execute_command_internal ()
> #30 0x00038638 in execute_command ()
> #31 0x000374c4 in execute_command_internal ()
> #32 0x00038638 in execute_command ()
> #33 0x000279c8 in reader_loop ()
> #34 0x0002751c in main For this(gdb) frame 1
> #1 0x000ab3dc in ()
> (gdb) disass 0x000ab3cc 0x000ab3ec
> Dump of assembler code from 0xab3cc to 0xab3ec:
> 0x000ab3cc: stw ret0,1c8(r8)
> 0x000ab3d0: copy r5,r26
> 0x000ab3d4: b,l 0x798d0,rp
> 0x000ab3d8: ldi df,r25
> 0x000ab3dc: b,l 0xab188,r0
> 0x000ab3e0: copy r3,ret0
> 0x000ab3e4: ldi -21,ret0
> 0x000ab3e8: stb ret0,0(r22)
> End of assembler dump
> (gdb) p/x $rp
> $1 = 0xab3df
> (gdb) disass 0x798d0 0x798e0
> Dump of assembler code from 0x798d0 to 0x798e0:
> 0x000798d0: addil L%5000,dp,r1
> 0x000798d4: ldw 524(r1),r21
> 0x000798d8: bv r0(r21)
> 0x000798dc: ldw 528(r1),r19
> End of assembler dump.
> (gdb) p/x $dp
> $2 = 0xca1c8
> (gdb) p/x $r1
> $3 = 0xcf1c8
> (gdb) p/x $r21
> $4 = 0x0
> (gdb) p/x $r1+0x524
> $5 = 0xcf6ec
> (gdb) x/x 0xcf6ec
> 0xcf6ec: 0x40488250
> (gdb) disass 0x40488250
> Dump of assembler code for function *__GI_memset:
> 0x40488250 <*__GI_memset+0>: cmpib,>>= 7,r24,0x404882f8 <*__GI_memset+168>
> 0x40488254 <*__GI_memset+4>: copy r26,r22
> 0x40488258 <*__GI_memset+8>: extrw,u r25,31,8,r31
> ...
Could it be, that always r21 and r22 are involved?
Maybe we don't restore them correctly after some syscalls like fork / getpwnam...?
Esp. the comment for r21-r22 in arch/parisc/kernel/entry.S:1708 seems interesting:
/* Register saving semantics for system calls:
%r1 clobbered by system call macro in userspace
%r2 saved in PT_REGS by gateway page
%r3 - %r18 preserved by C code (saved by signal code)
%r19 - %r20 saved in PT_REGS by gateway page
%r21 - %r22 non-standard syscall args
stored in kernel stack by gateway page
%r23 - %r26 arg3-arg0, saved in PT_REGS by gateway page
%r27 - %r30 saved in PT_REGS by gateway page
%r31 syscall return pointer
*/
Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
