[Bug gas/19576] bogus code generation with on SunOS with 2.26
https://sourceware.org/bugzilla/show_bug.cgi?id=19576 --- Comment #10 from Richard PALO --- Since this affects, in principle, *any* dtrace implementation including *bsd, linux, ... I'm inclined to ask the question whether there is any way to force ELF symtab generation *not* to optimise with substrings... if not, perhaps an attribute or pragma may be useful to indicate that the symbol name itself is volatile (just thinking out loud). That is, it may be a certain while before any workaround to dtrace comes about adding, instead of replacing, dtrace related symbols and, in particular, before a solution of this kinds gets any wide cross-platform adoption. -- 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/19576] bogus code generation with on SunOS with 2.26
https://sourceware.org/bugzilla/show_bug.cgi?id=19576 --- Comment #11 from H.J. Lu --- (In reply to Richard PALO from comment #10) > Since this affects, in principle, *any* dtrace implementation including > *bsd, linux, ... I'm inclined to ask the question whether there is any way > to force ELF symtab generation *not* to optimise with substrings... if not, > perhaps an attribute or pragma may be useful to indicate that the symbol > name itself is volatile (just thinking out loud). > > That is, it may be a certain while before any workaround to dtrace comes > about adding, instead of replacing, dtrace related symbols and, in > particular, before a solution of this kinds gets any wide cross-platform > adoption. The bug is in dtrace, which has nothing to do with binutils. I have no idea how to fix dtrace. -- 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/19576] bogus code generation with on SunOS with 2.26
https://sourceware.org/bugzilla/show_bug.cgi?id=19576 --- Comment #12 from Richard PALO --- I was referring to the code generation (here, .symtbl) change between 2.25.1 and 2.26.0 where the problem became apparent... It would be useful to have a means to enforce the previous behaviour (read: which worked okay with dtrace). -- 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/19576] bogus code generation with on SunOS with 2.26
https://sourceware.org/bugzilla/show_bug.cgi?id=19576 --- Comment #13 from H.J. Lu --- (In reply to Richard PALO from comment #12) > I was referring to the code generation (here, .symtbl) change between 2.25.1 > and 2.26.0 where the problem became apparent... > It would be useful to have a means to enforce the previous behaviour (read: > which worked okay with dtrace). It is done by commit ef10c3ace00674e8c3599c3bf95f06c87d68898b Author: H.J. Lu Date: Thu Jun 25 08:16:00 2015 -0700 Use strtab with GC and suffix merging for .strtab I don't believe we can go back. -- 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 ld/20360] New: DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 Bug ID: 20360 Summary: DT_TEXTREL appearing in output with no textrels on x86_64 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- This is based on a bug report from dotnet CoreCLR: https://github.com/dotnet/coreclr/issues/6211 What seems to be happening is that bfd ld is producing a DT_TEXTREL header in the output shared library despite it not having any actual textrels (according to scanelf and manual reading of readelf output). This results in a library that is not loadable on hardened kernels (due to rejected mprotect operation), despite the fact that no relocations in the writable LOAD segment are actually needed/present. I have reviewed the readelf outputs but not the actual files and I have not performed the build myself. I'm asking the dotnet folks to follow up on this bug report with additional information. -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-07-12 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- Please provide a testcase. -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 Peter Jas changed: What|Removed |Added CC||danglingpointer at live dot com --- Comment #2 from Peter Jas --- Created attachment 9385 --> https://sourceware.org/bugzilla/attachment.cgi?id=9385&action=edit "readelf -aW libcoreclr.so" dump (with -BSymbolic) readelf output of libcoreclr.so, when I built coreclr in a normal way on Alpine Linux. -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 --- Comment #3 from Rich Felker --- At this point there's no testcase smaller than the dotnet/coreclr build, but I wanted to go ahead and post the bug here to get discussion moved to the tracker where it's relevant. I believe they have a way to slightly reduce the testcase by only linking a subset of what would normally go into the library. Waiting for their followup. -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 --- Comment #4 from Peter Jas --- Created attachment 9386 --> https://sourceware.org/bugzilla/attachment.cgi?id=9386&action=edit "readelf -aW libcoreclr.so" dump (without -XLinker -BSymbolic -XLinker -BSymbolic-functions) readelf output of libcoreclr.so, when I built it without "-XLinker -BSymbolic -XLinker -BSymbolic-functions" on Alpine Linux. -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 --- Comment #5 from Peter Jas --- Thanks Rich. I am not the dotnet folk per-se; just contributed some port related PR to the coreclr repo and such. Should we ping someone on the GitHub issue if more information is required? I have uploaded two dumps of readelf -aW: t1: the normal build (git clone https://github.com/dotnet/coreclr && coreclr/build.sh && readelf -aW coreclr/bin/Product/Linux.x64.Debug/libcoreclr.so) t2: once the normal build is done, I found that the linker command for libcoreclr.so is as described here: https://github.com/dotnet/coreclr/issues/6211#issuecomment-231615572. So I ran this command in the specified subdir without -XLinker -BSymbolic -XLinker -BSymbolic-functions. Let me know if anything else is needed. -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 --- Comment #6 from Rich Felker --- To add some context, I suggested building without -Bsymbolic* in case the cause was relocations that would be textrels before -Bsymbolic* optimized them out. Looking at the source, particularly calls/jmps to C functions from asm source files without @plt, I would expect to see these in the readelf output without -Bsymbolic*, but I don't... -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 --- Comment #7 from H.J. Lu --- I need the linker input so that I can reproduce the linker output. Binary inputs are OK. -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 --- Comment #8 from Peter Jas --- Here is the corresponding linker command (without -BSymbolic* , when I ran clang++ command with -v in coreclr/bin/obj/Linux.x64.Debug/src/dlls/mscoree/coreclr directory): "/usr/bin/ld" -z now -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -shared -o libcoreclr.so /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../crti.o /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/5.3.0/crtbeginS.o -L/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/5.3.0 -L/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../../x86_64-alpine-linux-musl/lib -L/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../.. -L/usr/bin/../lib -L/lib -L/usr/lib --version-script=/home/peterj/coreclr/bin/obj/Linux.x64.Debug/src/dlls/mscoree/coreclr/coreclr.exports --build-id=sha1 -soname libcoreclr.so CMakeFiles/coreclr.dir/__/mscoree.cpp.o CMakeFiles/coreclr.dir/__/unixinterface.cpp.o CMakeFiles/coreclr.dir/__/__/__/__/version.cpp.o ../../../utilcode/dyncrt/libutilcode.a --start-group ../../../debug/ee/wks/libcordbee_wks.a ../../../debug/debug-pal/libdebug-pal.a ../../../unwinder/wks/libunwinder_wks.a ../../../vm/wks/libcee_wks.a ../../../gc/wks/libgc_wks.a --end-group ../../../md/compiler/wks/libmdcompiler_wks.a ../../../md/runtime/wks/libmdruntime_wks.a ../../../md/enc/wks/libmdruntimerw_wks.a ../../../md/hotdata/full/libmdhotdata_full.a ../../../classlibnative/bcltype/libbcltype.a ../../../md/ceefilegen/libceefgen.a ../../../classlibnative/float/libcomfloat_wks.a ../../../inc/libcorguids.a ../../../gcinfo/lib/libgcinfo.a ../../../debug/ildbsymlib/libildbsymlib.a ../../../strongname/api/wks/libstrongname_wks.a ../../../utilcode/dyncrt/libutilcode.a ../../../binder/v3binder/libv3binder.a --whole-archive ../../../pal/src/libcoreclrpal.a ../../../pal/src/libtracepointprovider.a --no-whole-archive ../../mscorrc/full/libmscorrc_debug.a ../../../palrt/libpalrt.a ../../../pal/src/eventprovider/libeventprovider.a ../../../nativeresources/libnativeresourcestring.a -lgcc_s -lpthread -lrt -ldl -luuid -lunwind -lunwind-generic -lunwind-x86_64 -lintl -lstdc++ -lm -lgcc_s -lc -lgcc_s /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/5.3.0/crtendS.o /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../crtn.o -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 --- Comment #9 from H.J. Lu --- Please provide the smallest set of linker inputs which can reproduce the problem. -- 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
