Am Dienstag 30 April 2013, 10:45:54 schrieb John David Anglin:
> On 4/30/2013 10:02 AM, Rolf Eike Beer wrote:
> > Am 30.04.2013 15:00, schrieb John David Anglin:
> >> On 30-Apr-13, at 5:37 AM, Rolf Eike Beer wrote:
> >>> Compiling for my C8000 (64 bit) failed:
> >>>
> >>> *arch/parisc/kernel/built-in.o: In function `sys_fork_wrapper':
> >>> *(.text+0x4dc8): relocation truncated to fit: R_PARISC_PCREL17F
> >>> against symbol
> >>> `sys_fork' defined in .text.sys_fork section in kernel/built-in.o
> >>> *hppa64-unknown-linux-gnu-ld: arch/parisc/kernel/built-in.o(.text
> >>> +0xllx):
> >>> cannot reach (null)
> >>> *arch/parisc/kernel/built-in.o: In function `sys_vfork_wrapper':
> >>> *(.text+0x4e1c): relocation truncated to fit: R_PARISC_PCREL17F
> >>> against symbol
> >>> `sys_vfork' defined in .text.sys_vfork section in kernel/built-in.o
> >>> *make: *** [vmlinux] Error 1
> >>
> >> Some form of a 17-bit branch has been used (e.g., b), to branch to
> >> sys_fork. Assume
> >> you are building without modules, so you have a big kernel.
> >
> > I have modules, but I had seen an error before so I tried enabling
> > longcalls. Currently building without MLONGCALLS with new binutils to
> > see if it works then, i.e. the error below goes away.
>
> Longcalls will not fix the above. The option doesn't affect assembly code.
>
> A "b" instruction is not a "call". By that, I mean that the linker
> doesn't add long call stubs, etc. It only
> supports a 17-bit pc-relative offset. The prelinking done by linux can
> result in objects that are too big
> and out of range branches as above.
>
> >> Problem seems to be here:
> >> .macro fork_like name
> >>
> >> ENTRY(sys_\name\()_wrapper)
> >>
> >> LDREG TI_TASK-THREAD_SZ_ALGN-FRAME_SIZE(%r30), %r1
> >> ldo TASK_REGS(%r1),%r1
> >> reg_save %r1
> >> mfctl %cr27, %r28
> >> b sys_\name
> >> STREG %r28, PT_CR27(%r1)
> >>
> >> ENDPROC(sys_\name\()_wrapper)
> >>
> >> .endm
> >>
> >> If %r2 can be clobbered, the "b" instruction could be changed to the
> >> "BL" macro.
> >> This would give 22-bit branch on PA 2.0. For example,
> >>
> >> BL sys_\name, %r2
>
> Does this work? I think %r2 should be available but I can't check at
> the moment.
Have not tried yet.
> >>> This is after I enabled MLONGCALLS, witho
> >>> ut longcalls it failed, too. I'm now
> >>> trying with binutils 2.23.1 instead of 2.22.
> >>
> >> The above is not a binutils bug!
> >
> > Nope, but probably this:
> >
> > *hppa64-unknown-linux-gnu-ld: scripts/link-vmlinux.sh: line 52: 5398
> > Segmentation fault ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T
> > ${lds} ${KBUILD_VMLINUX_INIT} --start-group ${KBUILD_VMLINUX_MAIN}
> > --end-group ${1}
>
> No, it's probably a kernel bug. Is the crash consistent? If it isn't,
> then it's an OS or kernel bug.
I have got the same crash again. This are the first 2 tries I ever made with
binutils 2.23.1 for 64 bit binaries, so I have nothing to compare to.
EikeAttachment:
signature.asc
Description: This is a digitally signed message part.
