[Bug binutils/19260] New: 32-bit Solaris libc has a limit of maximum 255 open file descriptors
https://sourceware.org/bugzilla/show_bug.cgi?id=19260
Bug ID: 19260
Summary: 32-bit Solaris libc has a limit of maximum 255 open
file descriptors
Product: binutils
Version: 2.25
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: stefan.teleman at oracle dot com
Target Milestone: ---
Created attachment 8792
--> https://sourceware.org/bugzilla/attachment.cgi?id=8792&action=edit
cache.c.patch
The 32-bit Solaris libc (both on Intel and SPARC) can only handle 255
open file descriptors. The reason for this limitation in 2015 is historical.
To make things worse: a process can call setrlimit(RLIMIT_NOFILE, &rlim)
and raise the current number of allowable file descriptors to more than 255.
But this doesn't mean that libc will actually be able to handle them without
some additional acrobatics. This will lead to a very interesting situation:
a caller can call getrlimit(RLIMIT_NOFILE, &rlim), and obtain a value for
rlim.rlim_cur that is invalid in 32-bit Solaris libc.
Unfortunately, this is what is happening in binutils 2.25.1,
in ${top_srcdir}/bfd/cache.c. The function
static int bfd_cache_max_open (void);
will try to determine how many file descriptors it can cache based on the
result from getrlimit(2). If a binutils program is running from within
another program which has raised RLIMIT_NOFILE to 65536 (for example), libbfd
will correctly assume that 8192 file descriptors are safe to cache (65536 / 8).
Unfortunately, that is not the case in Solaris 32-bit libc.
I am proposing a Solaris-specific patch here, which deals with this problem.
It is not elegant by any means, but it cures this problem in Solaris 32-bit,
and without affecting any other bfd target.
64-bit Solaris libc does not have this limitation.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19260] 32-bit Solaris libc has a limit of maximum 255 open file descriptors
https://sourceware.org/bugzilla/show_bug.cgi?id=19260 Stefan Teleman changed: What|Removed |Added CC||stefan.teleman at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19260] 32-bit Solaris libc has a limit of maximum 255 open file descriptors
https://sourceware.org/bugzilla/show_bug.cgi?id=19260 Stefan Teleman changed: What|Removed |Added CC||stefan.teleman at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20427] New: Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 Bug ID: 20427 Summary: Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables Product: binutils Version: 2.25 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: stefan.teleman at oracle dot com Target Milestone: --- Host: sparc-sun-solaris2.12 Target: sparc-sun-solaris2.12 Created attachment 9415 --> https://sourceware.org/bugzilla/attachment.cgi?id=9415&action=edit test case demonstrating the bug This bug is present in Binutils 2.25.1 and 2.26.1. This bug can be verified on Solaris 11 as well as Solaris 12. With a hand-written SPARC assembler translation unit, containing the following: .data .align 8 .global .gomp_critical_user_ .comm .gomp_critical_user_, 64, 8 The resulting 32-bit SPARC *.o ELF -- asembled with gas - is then linked into a shared library. When linking this shared library in a 32-bit SPARC program, trying to run the test program results in: ld.so.1: main32: fatal: relocation error: file /builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas/libtest32.so: symbol .gomp_critical_user_: invalid relocation type for ELFCLASS32: 54 ./testit-gcc.sh: line 29: 441437 Killed ./main32 The link-editing itself succeeds without warnings. The attachment gnu-as-bad-reloc-test.tar.bz2 demonstrates the bug. The proposed patch (attached) cures this bug. The 32-bit test program now succeeds, and works as expected. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 Stefan Teleman changed: What|Removed |Added CC||stefan.teleman at oracle dot com --- Comment #1 from Stefan Teleman --- Created attachment 9416 --> https://sourceware.org/bugzilla/attachment.cgi?id=9416&action=edit proposed patch -- tc-sparc.c.patch Proposed patch. This patch applies cleanly to Binutils 2.25.1 and 2.26.1 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 Stefan Teleman changed: What|Removed |Added CC||ro at gcc dot gnu.org, ||stefan.teleman at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 --- Comment #2 from Stefan Teleman --- All gas tests on Solaris SPARC pass after applying the proposed patch. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 --- Comment #4 from Stefan Teleman --- Hi Nick, (In reply to Nick Clifton from comment #3) > Hi Stefan, > > > proposed patch -- tc-sparc.c.patch > > I have a couple of questions about this patch: > > 1. There appear to be other places in cons_fix_new_sparc() where > 64-bit relocs can be generated (ie BFD_RELOC_64_PCREL, > BFD_RELOC_SPARC_PLT64 and BFD_RELOC_SPARC_TLS_DTPOFF64) but the > patch does not affect them. Why not ? Mainly because i haven't been able to come up with a test case which would trigger gas to emit these 64-bit relocations in 32-bit. I can try coming up with test cases for these as well. This would actually be quite useful. > > 2. The relocs that you are changing are intended to install 64-bit > values into the binary. By changing them to 32-bit versions it > seems like you are loosing the upper bits. Have you run any tests > to see if 64-bit values are still handled correctly after applying > the patch ? [It would be useful to know what the Solaris assembler > does in these circumstances. Does it, for example, produce two > 32-bit relocs, one for the lower 32-bits and one for the upper > 32-bits ?] I have verified that the values are being handled correctly with the gas + Solaris ld combination. The Solaris SPARC assembler can't hanlde .8byte. So, i have to use .xword, which isn't quite the same exact thing as .8byte. So, this is what happens if i re-write the test32.S program for the Sun SPARC assembler: ! test32-sun.S .data .align 8 .global .gomp_critical_user_ .comm .gomp_critical_user_, 64, 8 .type .gomp_critical_user_,#object .size .gomp_critical_user_, 64 .data .global __kmp_unnamed_critical_addr __kmp_unnamed_critical_addr: .xword .gomp_critical_user_ .type __kmp_unnamed_critical_addr,#object .size __kmp_unnamed_critical_addr, .-__kmp_unnamed_critical_addr .file "test32-sun.S" [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 6:49:34][536]>> /usr/bin/as -m32 -xarch=v8plusa test32-sun.S -o test32-sun.o [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 6:49:36][537]>> readelf -sW --relocs test32-sun.o Relocation section '.rela.data' at offset 0xf8 contains 1 entries: Offset InfoTypeSym. Value Symbol's Name + Addend 0004 0303 R_SPARC_32 0008 .gomp_critical_user_ + 0 Symbol table '.symtab' contains 5 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 FILELOCAL DEFAULT ABS test32-sun.S 2: 0 SECTION LOCAL DEFAULT2 3: 000864 OBJECT GLOBAL DEFAULT COM .gomp_critical_user_ 4: 8 OBJECT GLOBAL DEFAULT2 __kmp_unnamed_critical_addr So, as you can see, the Sun SPARC assembler emitted a R_SPARC_32 relocation for .gomp_critical_user_. By comparison, GAS with my proposed patch emits this: [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 6:50:56][540]>> readelf -sW --relocs test32-new.o Relocation section '.rela.data' at offset 0x140 contains 1 entries: Offset InfoTypeSym. Value Symbol's Name + Addend 0617 R_SPARC_UA32 0008 .gomp_critical_user_ + 0 Symbol table '.symtab' contains 8 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 FILELOCAL DEFAULT ABS test32.S 2: 0 SECTION LOCAL DEFAULT1 3: 0 SECTION LOCAL DEFAULT2 4: 0 SECTION LOCAL DEFAULT4 5: 0 SECTION LOCAL DEFAULT5 6: 000864 OBJECT GLOBAL DEFAULT COM .gomp_critical_user_ 7: 8 OBJECT GLOBAL DEFAULT2 __kmp_unnamed_critical_addr But, you are absolutely right in saying that I should come up with test cases and proposed patches for all the other possible 64-bit relocations for 32-bit cases. So, please stay tuned. :-) And thank you very much for looking at this proposed patch so quickly!! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 --- Comment #6 from Stefan Teleman --- If i change the test case for the Sun assembler: __kmp_unnamed_critical_addr: .xword .gomp_critical_user_ + 0x1234567890 i get this: [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 7:30:35][544]>> /usr/bin/as -m32 -xarch=v8plusa test32-sun.S -o test32-sun.o /usr/bin/as: "test32-sun.S", line 14: warning: value does not fit in 32 bits [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 7:30:43][545]>> readelf -sW --relocs test32-sun.o Relocation section '.rela.data' at offset 0xf8 contains 1 entries: Offset InfoTypeSym. Value Symbol's Name + Addend 0004 0303 R_SPARC_32 0008 .gomp_critical_user_ + 34567890 Symbol table '.symtab' contains 5 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 FILELOCAL DEFAULT ABS test32-sun.S 2: 0 SECTION LOCAL DEFAULT2 3: 000864 OBJECT GLOBAL DEFAULT COM .gomp_critical_user_ 4: 8 OBJECT GLOBAL DEFAULT2 __kmp_unnamed_critical_addr Same as GAS, but the Sun assembler emits a warning. Which now creates a new and interesting question that i am going to run by the Solaris linker people: isn't this a Solaris rtld bug, in final analysis? I will ask the linker folks and i will come up with more test cases for the other relocations. Thank you very much! --Stefan -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
