[Bug ld/15095] New: Offset of DT_STRTAB is incorrect on executables
http://sourceware.org/bugzilla/show_bug.cgi?id=15095 Bug #: 15095 Summary: Offset of DT_STRTAB is incorrect on executables Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sourceware.org ReportedBy: jpakk...@gmail.com Classification: Unclassified The ELF specification for dynamic sections says the following about DT_STRTAB: This element holds the address of the string table, described in Part 1. Symbol names, library names, and other strings reside in this table. However the offset of this value is incorrect for executables. This is easy to verify with this command: readelf -d /usr/bin/lsusb | grep STRTAB which produces this output: 0x0005 (STRTAB) 0x400970 The offset given points past the end of the binary. The returned offset is valid if the file is a shared library: readelf -d /usr/lib/libblas.so.3 | grep STRTAB 0x0005 (STRTAB) 0x2c18 The value of .dynstr in the header is correct in both cases. Tested on 64 bit Linux. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/16388] New: Linking with Gold causes threading strange threading issues
https://sourceware.org/bugzilla/show_bug.cgi?id=16388 Bug ID: 16388 Summary: Linking with Gold causes threading strange threading issues Product: binutils Version: 2.24 Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ian at airs dot com Reporter: jpakkane at gmail dot com CC: ccoutant at google dot com We have discovered an issue where linking with Gold (on x86-64 without using lto or any other fancy machinery) causes problems in multithreaded code. More specifically code that functions perfectly with bfd hangs, freezes or segfaults when linked with Gold. We have not been able to reduce this to a simple test case but this is how to replicate the issue. First you need to install the dependency, which is Unity-api (https://launchpad.net/unity-api). This is available in Ubuntu 14/04 development version (and possibly 13/10). Otherwise you need to compile from source. Then do this to compile and test the regular bfd version: bzr branch lp:unity-scopes-api (current trunk rev is 114) cd unity-scopes-api mkdir build cd build cmake -DCMAKE_BUILD_TYPE=debug .. make test/gtest/scopes/internal/Reaper/Reaper_test This works reliably. Then do a Gold build: mkdir buildgold cd buildgold LDFLAGS=-fuse-ld=gold cmake -DCMAKE_BUILD_TYPE=debug .. make test/gtest/scopes/internal/Reaper/Reaper_test This almost always hangs or sometimes segfaults. It may well be that our code has a bug and Gold only makes it surface. However we have spent quite a lot of time looking into our code and as far as we can tell the code should not have bugs. -- 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/22843] New: Provide dependency information from the linker similar to the compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=22843 Bug ID: 22843 Summary: Provide dependency information from the linker similar to the compiler Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: jpakkane at gmail dot com Target Milestone: --- The -M flag and its like is very useful for reliable dependencies when compiling. It would be great if the same would work also when linking. The use case is the following. Suppose you build a project with a dependency that comes in via pkg-config. The eventual link line looks like this: gcc -o final_exe source.o -L/path/to/my/place -L/path/to/somewhere/else -lmydep It is very difficult to tell where the dependency library will be picked up from. If the user updates any library by doing a "make/ninja install" from the dependency file, then it is hard to know that the dependency libraries have changed and thus require a rebuild. (usually doing an install updates headers, which _do_ trigger a rebuild but some systems only overwrite installed files if they have changed so looking only at header files is not reliable). If ld supported generating dependency files like gcc with -M does for source compilations, this problem would go away because running make/ninja would automatically detect changes in system directories. -- 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/22843] Provide dependency information from the linker similar to the compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=22843 --- Comment #2 from jpakkane at gmail dot com --- The point of this request is to integrate the linker's dependency list with Make and Ninja. The way the workflow would go (and already does for compilers) is the following: - the linker gets invoked with a flag to write the dep file - it gets written to libresult.so.d (or somesuch) - _immediately_ after the process has finished, Make or Ninja loads the contents of the file and stores it in their internal data storage - in case of Ninja, it immediately deletes the .d file after it has read it, this makes a big performance difference on Windows As can be seen, getting the dependency info in the correct format is necessary, because it is immediately consumed. Needing to do a conversion means that everyone who wants to use this feature needs to wrap all linker invocations in a custom script. -- 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/22843] Provide dependency information from the linker similar to the compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=22843 --- Comment #4 from jpakkane at gmail dot com --- There is an extra twist for this. In Meson (and also in buildsystems of Chrome and Libreoffice) we use the symbol list to skip relinks. That is, if the list of exported symbols for a given shared library has not changed, we skip relinking dependent targets that are not out-of-date due to some other reason (such as headers changing). If we add direct dependencies to the .so files via this dependency file, this optimization no longer works. It would be nice if the solution to this problem could be made to work together with this. The code that does this extraction for Meson is here: https://github.com/mesonbuild/meson/blob/master/mesonbuild/scripts/symbolextractor.py -- 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
