RE: 3.18+: soft-float userland unusable due to .MIPS.abiflags patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Manuel Lauss <manuel.lauss@xxxxxxxxx> writes:
> On Fri, Jan 16, 2015 at 9:01 PM, Manuel Lauss <manuel.lauss@xxxxxxxxx>
> wrote:
> > On Fri, Jan 16, 2015 at 8:12 PM, Matthew Fortune
> > <Matthew.Fortune@xxxxxxxxxx> wrote:
> >>> On Fri, Jan 16, 2015 at 6:59 PM, Manuel Lauss
> >>> <manuel.lauss@xxxxxxxxx>
> >>> wrote:
> >>> > Hi Paul,
> >>> >
> >>> > Your patch commit 90cee759f08a6b7a8daab9977d3e163ebbcac220
> >>> > ("MIPS: ELF: Set FP mode according to .MIPS.abiflags") completely
> >>> > breaks my pure soft-float o32 userland:
> >>> >
> >>> > [...]
> >>> > Freeing unused kernel memory: 244K (80993000 - 809d0000) Failed to
> >>> > execute /usr/lib/systemd/systemd (error -84).  Attempting
> defaults...
> >>> > Starting init: /sbin/init exists but couldn't execute it (error
> >>> > -84)
> >>> > sh: cannot set terminal process group (-1): Inappropriate ioctl
> >>> > for device
> >>> > sh: no job control in this shell
> >>> > sh-4.3# ls
> >>> > sh: /bin/ls: Accessing a corrupted shared library sh-4.3#
> >>> >
> >>> > I've recently rebuilt bash, ncurses, readline and glibc-2.20 (with
> >>> > binutils 2.25+) to track down another userland issue, so that may
> >>> > explain why at least sh is able to run.
> >>>
> >>> Although ls and all its dependencies have the following soft-float
> >>> abi
> >>> tag:
> >>> Displaying notes found at file offset 0x00000164 with length
> 0x00000020:
> >>>   Owner                 Data size       Description
> >>>   GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version
> tag)
> >>>     OS: Linux, ABI: 2.6.32
> >>> Attribute Section: gnu
> >>> File Attributes
> >>>   Tag_GNU_MIPS_ABI_FP: Soft float
> >>
> >> Can you provide the output of readelf -hl for 'ls', 'init' and
> >> whatever is listed as the interpreter for those executables in the
> >> header output shown
> >> like:
> >>
> >>   INTERP         0x0000000000000238 0x0000000000400238
> 0x0000000000400238
> >>                  0x000000000000001c 0x000000000000001c  R      1
> >>       [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
> 
> 
> I noticed that /bin/sh does have a .MIPS.abiflags section while systemd
> and ls do not.  Maybe that's the issue here?
> 
>  Section to Segment mapping:
>   Segment Sections...
>    00
>    01     .interp
>    02     .MIPS.abiflags

It is the ABIFLAGS program header that I am focussed on but the presence of
a .MIPS.abiflags section is a strong indicator that there will be an
ABIFLAGS pheader. The key is in the readelf output for the interpreter i.e.
/lib/ld.so.1. I would expect it has the ABIFLAGS header too given you
said that you recently rebuilt glibc.

You are right that it is the .MIPS.abiflags patch that is causing your
trouble. For a long time I had to put a restriction in the ABI plan that
soft-float binaries without an ABIFLAGS pheader could not be linked against
soft-float binaries with an ABIFLAGS pheader. We have since found a way to
relax that restriction without reducing the effectiveness of the new
compatibility checks. I would need to check the code in the kernel but I 
suspect that is the issue. Markos has done a significant update to this
piece of code which he posted earlier today. That updated version should
allow the combination of soft-float without ABIFLAGS and soft-float with
ABIFLAGS.

Matthew




[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux