[Bug gold/30187] New: ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
Bug ID: 30187
Summary: ld.bfd and ld.gold versions in .comment section of ELF
files
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: tkacvins at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Using a simple "hello world!" program
#include
int main(int argc, char** argv)
{
printf("Hello world!\n");
return 0;
}
and then compiling with GCC 12.1 (or any GCC that supports -fuse-ld=gold)
gcc -fuse-ld=gold hello.c
Results in the ld.gold version not being in the .comment section. Ditto if one
uses ld.bfd.
However, if one uses a GCC that supports -fuse-ld=lld, one gets a linker
version in the .comment section
gcc -B /opt/lld-14.0.6/bin -fuse-ld=lld hello.c
$ readelf -p .comment a.out
String dump of section '.comment':
[ 0] GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-39)
[2d] Linker: LLD 14.0.6
[40] GCC: (GNU) 12.1.0
It would be nice if the gold and bfd linkers emitted their version into the
.comment section.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 Tom Kacvinsky changed: What|Removed |Added CC||tkacvins at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 --- Comment #2 from Tom Kacvinsky --- (In reply to Nick Clifton from comment #1) > (In reply to Tom Kacvinsky from comment #0) > Hi Tom, > > > Results in the ld.gold version not being in the .comment section. > > But - just to be clear - it is in the .note.gnu.gold-version section: > > % readelf -p.note.gnu.gold-version a.out > > String dump of section '.note.gnu.gold-version': > [ c] GNU > [10] gold 1.16 > > So this is a request for gold to add or move the version number into the > .comment section, right ? And add the feature to ld too, of course. Yes, this is correct - to make it more in line with what LLD does. > > > Note - it is possible to achieve the desired effect using an extra object > file: > > % cat ld-version.s > .section .comment > .asciz "GNU ld version 2.37-37.fc36"; > % gcc hello.c ld-version.s > % readelf -p.comment >[ 0] GCC: (GNU) 12.2.1 20221121 (Red Hat 12.2.1-4) >[2e] GCC: (GNU) 12.0.1 20220413 (Red Hat 12.0.1-0) >[5c] GNU ld version 2.37-37.fc36 > > But I am sure that this is not what you want. > This is feasible in that we can use cmake to generate the .s file, or perhaps generated a new object file everything we upgrade binutils. But... > Hmm, let me see if it is an easy thing to do... This would be ideal if you or someone on the binutils team can do it. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 --- Comment #5 from Tom Kacvinsky --- (In reply to Nick Clifton from comment #4) > (In reply to Nick Clifton from comment #3) > > > What do you think of the this patch ? > > I have discovered a flaw in the patch. :-( > > Since the version string is now present in the .comment section, that > section is always output, even if there are no input files containing > .comment sections. This breaks many of the linker's own tests and > represents unexpected new behaviour of the linker. *sigh* I will have to > rethink my solution. I'd be OK with a new option. That way, old tests can be such that the new option is not used, the .comment section is not emitted, and things are as they were. Then, write a new test (or tests) that exercise the new option. I see there is often a lot of back and forth on the binutils list about what options should be named, but just as a first stabd, I'd call it "--emit-comment-section" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 --- Comment #6 from Tom Kacvinsky --- I found an issue with the patch. I applied against master and built it. I then used gcc 12.1.0 and got this: $ /opt/gcc-12.1.0/bin/gcc -B /opt/binutils-2.40-version/bin -fuse-ld=bfd -o wchar wchar.c /opt/binutils-2.40-version/bin/ld.bfd: wchar: error: PHDR segment not covered by LOAD segment If I dump the default linker script and remove the linker version comment option, and use the resulting file as the link scriot: $ /opt/gcc-12.1.0/bin/gcc -B /opt/binutils-2.40-version/bin -fuse-ld=bfd -Wl,--script=noversion.script -o wchar wchar.c this problem goes away. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 --- Comment #8 from Tom Kacvinsky --- Created attachment 14752 --> https://sourceware.org/bugzilla/attachment.cgi?id=14752&action=edit simple C reproducer file -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
--- Comment #9 from Tom Kacvinsky ---
(In reply to Nick Clifton from comment #7)
> Created attachment 14751 [details]
> Proposed patch
>
> Hi Tom,
>
> (Sorry for the delay in updating this PR).
>
> Please could you try out this revised patch ?
>
> It uses the same LINKER_VERSION linker script directive, but this time it
> is also
> controlled via a new command line option: --enable-linker-version.
>
> I would be interested to know if the problem you observed compiling
> wchar.c returns, if you link with -Wl,--enable-linker-version. If it does,
> please could you upload the wchar.c or whcar.o files so that I can try for
> myself.
>
> Cheers
> Nick
I have attached the wchar.c file I am using. But this problem happens with an
even more simple C file
int main()
{
return 0;
}
The error with PHDR happens with use of -Wl,--enable-linker-version and
-fuse-ld=bfd, but not when --enable-linker-version is not used.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 --- Comment #11 from Tom Kacvinsky --- Hi Nick, This worked perfectly. The linker didn't throw the PHDR error, and the resulting executable now has the binutils version in the .comment section. Thank you very much for your work on this. So you know, the impetus for this is I build a lot of different things for my job and don't always remember to use the linker I should for code I am building. This will help me decipher if I used the right linker or not. Tom -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 --- Comment #16 from Tom Kacvinsky --- Nick, Worked great! Thanks! Tom -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] New: ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 Bug ID: 30448 Summary: ld fails to make a valid DLL when used with gnatdll Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: tkacvins at gmail dot com Target Milestone: --- I found an issue when generating a DLL via gnatdll. The issue was introduced btween 2.33.1 and 2.34, and I believe it was this specific commit dc9bd8c92af6 which introduced --enable-reloc-section in pe.pem and pep.pem. So, 2.33.1, which didn't have this option, worked, and 2.34, which did have this option, did not. It was until 2.35 when the corresponding --disable-reloc-section was introduced that the problem was fixed. All I had to do is used --disable-reloc-section for my linker options and the DLL generated by gnatdll went away. This option works all the way through 2.40. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #2 from Tom Kacvinsky --- Yes, --disable-reloc-section is a viable workaround. And it can be added to the gnatdll option -largs (which is the option that allows you to specify options to the linker). I would have to check to see if an MSVC DLL has a .reloc section. If it doesn't, it could just be the presence of the .reloc section that cause the problem, or how it is set up to be referenced in the DLL. If an MSVC DLL has a .reloc section (I think they call it an .rdata section, but I am not sure), then it might be a relocation in the .reloc section is wrong. I have no non-Windows specific way of reproducing the problem. This is a Windows only issues as it involves the Windows PE code in binutils. I'll look into the .reloc section stuff today. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #3 from Tom Kacvinsky ---
Have a different take on this issue now. I was able to get 2.34 working. I
had to modify pep.em to get it to build on MSYS2 + MinGW-w64.
The commit that was partially reverted was 1ff6de031241. In that commit there
was this section of code
${LDEMUL_EMIT_CTF_EARLY-NULL}
which the genscripts.sh script did not like (it was one of the few things that
cased a hang in that script). Replacing that by just NULL, as well as doing
the same for
${LDEMUL_EXAMINE_STRTAB_FOR_CTF-NULL}
and a few other constructs like that helped with the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #4 from Tom Kacvinsky --- Created attachment 14882 --> https://sourceware.org/bugzilla/attachment.cgi?id=14882&action=edit pep.em patch Attached is the patch for pep.em that fixed the problem in binutils 2.34 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #5 from Tom Kacvinsky --- I've conflated things. The issues of building binutils 2.34 and 2.35 on MinGW-w64 is a separate issue (perhaps an issue the MInGW-w64 folks know about and could help solve my build problems without hacks). I now have 2.34 and 2.35 building. As a starting point, I built our product with binutils 2.30 and GCC 121.1.0. This build was successful in the sense the application did not crash on start. Then, I bisected between 2.31 and 2.37 and found the break happened at 2.36. I scripted the steps gnatdll would use to make a DLL, then just changed which version of binutils I used in that script. At 2.36, I saw a break - a way around it is to use --disable-reloc-section. I just wanted to clarify the breakage happens at 2.36 and the other issues were not germane. An interesting observation the the --base-file output between 2.35 and 2.36 with --disable-reloc-section do not differ when using cmp -s. The .exp disassembles via objdump -Da (it's a PE image) to differ in one two byte sequence. objdump -p (relocation information) on the DLLs shows there is minimal difference (just timestamp and checksum, etc...) and most importantly, the relocations were exactly the same. So that's a +1. However, when using 2.36 without --disable-reloc-section, the base files fail a binary comparison to 2.35 (they should be the same, as they're to carry relocation offsets written out by cofflink.c). The exp files also disassemble with a multitude of differences (again, looking at differences of objdump -Da output with diff -u). The dump of the DLLs relocation tables obtained by objdump -p also show a multitude of differences - mostly relocations. So yeah, definite difference between 2.35 and 2.36 with relocation handling. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #7 from Tom Kacvinsky --- I don't understood _why_ those patches introduced the issue. Looking at them, one was from 2018, and the problem started sometime after 2019, and the other patches are changing ld options for DLL characteristics, but I saw nothing in them that would change how to relocations are generated. You'd think that for a DLL, you would always want a .reloc section and so disabling it should cause an issue (not the other way around), and my understanding is the DLL characteristics are just a guide to the run time loader, anyway. I can play around with the options those patches introduced if I can see if enabling/disabling them makes a difference. Anyway, it'd be great if that question could be answered. If not, I'll just carry on with my workaround without understanding why. It does bother my "Mr. Definitive" take on issues like this, but hey, sometimes you can't let perfect be the enemy of the done. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #8 from Tom Kacvinsky --- I think it was actually this commit dc9bd8c92af67947db44b3cb428c050259b15cd0 That had pep_dll_enable_reloc_section = 1 only if --enable-dynamicbase was specified (which we hadn't been doing). Later on in, in commit 514b4e191d5f it was enabled by default, irrespective of --enable-dynamicbase or --enable-reloc-section being specified. So I think the crucial commit that didn't take full effect by default until later is dc9bd8c92af67947db44b3cb428c050259b15cd0. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #10 from Tom Kacvinsky --- The problem is an access violation at startup, deep in the guts of the DLL loader. Doing a debug session with Visual Studio and looking at registers and memory locations, it was determined that loading the DLL in question is where things went south. And, for what it's worth, perhaps --disable-reloc-section is not a good name for an option - the DLL I produced with that option does have a .reloc section. So what exactly does --disable-reloc-section mean if specifying that option still results in a DLL with a .reloc section? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #12 from Tom Kacvinsky --- (In reply to Eric Botcazou from comment #11) > > The problem is an access violation at startup, deep in the guts of the DLL > > loader. Doing a debug session with Visual Studio and looking at registers > > and memory locations, it was determined that loading the DLL in question is > > where things went south. > > For a DLL generated by GNAT? Which version of GNAT is that? GNAT that comes from GCC 12.1.0. I am using MSYS2 + MinGw-w64 for my base setup, then compile a custom GCC 12.1.0 with mingw-w64-crt v10.0.0 and binutils 2.38. This includes MinGW-w64's support for the UCRT, as we need that for the version of Visual Studio we also use to build out product. > > > And, for what it's worth, perhaps --disable-reloc-section is not a good name > > for an option - the DLL I produced with that option does have a .reloc > > section. So what exactly does --disable-reloc-section mean if specifying > > that option still results in a DLL with a .reloc section? > > So it generates a different .reloc section? Yes, binutils 2.35 generates a different .reloc section than binutils 2.36 (with default options) unless one uses binutils 2.36 with --disable-reloc-section. I shall gather what files I can attach that don't contains the proprietary binary code, just the relocation information. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #14 from Tom Kacvinsky --- Created attachment 14887 --> https://sourceware.org/bugzilla/attachment.cgi?id=14887&action=edit Dump of files as generated by binutils 2.35 and binutils 2.36 The files in this archive contain dumps of files generated by binutils 2.36 and 2.36. The .p files were generated by "objdump -p" and the .s files were generated by "objdump -Da". You will note that the .base file is different, and the that the relocation information in the dump of the DLL is different. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #15 from Tom Kacvinsky --- I am on vacation. When I get back, I will also upload the .exp file as generated by the Visual Studio tool chain. Because the final link done via gnatdll works with that .exp file, but not the one generated by dlltool. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
https://sourceware.org/bugzilla/show_bug.cgi?id=30448 --- Comment #16 from Tom Kacvinsky --- (In reply to Tom Kacvinsky from comment #14) > The files in this archive contain dumps of files generated by binutils 2.36 > and 2.36. The .p files were generated by "objdump -p" and the .s files were > generated by "objdump -Da". That should be "dumps of files generated by binutils 2.35 and 2.36." -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30493] New: PDB files generated by ld --pdb do not work with the Visual Studio debugger
https://sourceware.org/bugzilla/show_bug.cgi?id=30493 Bug ID: 30493 Summary: PDB files generated by ld --pdb do not work with the Visual Studio debugger Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: tkacvins at gmail dot com Target Milestone: --- This is a placeholder for an issue I have with PDB files generated by ld --pdb. I am using MSYS2 + MinGW-w64, with a built for source GCC 12.1.0 and binutils 2.40. I am not using the distribution's toolchain. But I _think_ this should reproduce if you use the latest MSYS2 + MinGW-w64 x86_64 toolchain. The issue is the PDB file being usable in the Visual Studio debugger. The PDB loads and I can hit breakpoints, but there is no source display when I hit the breakpoint. I will upload the PDB files as generated by GCC and Visual Studio for analysis. I will also use clang to generate a PDB file and see if that works with the Visual Studio debugger. If you want to try to reproduce before I can upload the files (which would be around June 6th), a simple hello world reproduced exhibits the problem. gcc -o hello -Wl,--pdb hello.c Then debug with Visual Studio's devenv devenv /debugexe hello.exe and set a break point on main and start debugging. You will break on main, but there will be no source display. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30493] PDB files generated by ld --pdb do not work with the Visual Studio debugger
https://sourceware.org/bugzilla/show_bug.cgi?id=30493 --- Comment #1 from Tom Kacvinsky --- (In reply to Tom Kacvinsky from comment #0) > gcc -o hello -Wl,--pdb hello.c That should be "gcc -g -o hello -Wl,--pdb hello.c" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30493] PDB files generated by ld --pdb do not work with the Visual Studio debugger
https://sourceware.org/bugzilla/show_bug.cgi?id=30493 --- Comment #2 from Tom Kacvinsky --- While binutils now understand how to write a PDB file, it needs the appropriate CodeView debug information in the object files/libraries fed to it. As things stand, GCC does not yet produce the CodeView debug information. There is a patch series for GCC to add support for CodeView debug information, but it has not been committed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27206] New: .symver overrides .weak
https://sourceware.org/bugzilla/show_bug.cgi?id=27206 Bug ID: 27206 Summary: .symver overrides .weak Product: binutils Version: 2.36 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: tkacvins at gmail dot com Target Milestone: --- Created attachment 13134 --> https://sourceware.org/bugzilla/attachment.cgi?id=13134&action=edit Reproducer code The attached code, when built with gcc -fPIC -o thread.so -shared thread.c (using GCC 8.3.0 and binutils 2.36) produces the following error: ld: thread.so: no symbol version section for versioned symbol `pthread_key_create@GLIBC_2.2.5' I am not sure if .symver is supposed to override .weak, or vice versa. IF the latter, it would appears to me that this is a bug in binutils. Regards, Tom -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27206] .symver overrides .weak
https://sourceware.org/bugzilla/show_bug.cgi?id=27206 --- Comment #2 from Tom Kacvinsky --- I know you mentioned this message comes from the referenced PR, but is what I am seeing an unintended consequence of the change made in this PR, or is this expected behavior? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27206] .symver overrides .weak
https://sourceware.org/bugzilla/show_bug.cgi?id=27206 --- Comment #4 from Tom Kacvinsky --- This worked for me in my simple reproducer, but unfortunately we are doing "naughty" things with third party code build such that a linker map is not an option, unless we hack that library's build process. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27206] .symver overrides .weak
https://sourceware.org/bugzilla/show_bug.cgi?id=27206 --- Comment #6 from Tom Kacvinsky --- For compatibility reasons, I want to update my automated build machine, but build GCC and auxiliary support libraries in such a fashion that we can target older Linux distributions That is, build on a machine with a newer glibc, but still be able to run the resulting binaries on a system with an older glibc, which is reverse of building on an older system and running on a newer system. So, I first went to build GCC 8.3.0 on a newer system (CentOS 7) using a custom assembly file (one that contains a .symver for each older version symbol we want, to target older versions of glibc). That is injected into compiler generated assembly files via an indirect assembler - named as, which opens any .s/.S files on the command line, inserts the custom assembly file into them, then calls gas, the _real_ assembler. But libgcc.so.1 failed to build with the pthread_key_create error I mentioned in this bug. The reproducer I sent is a stripped down version of the code from libgcc. This is why I am somewhat concerned about the link map trick, etc... It would create many problems while trying to sort out the GCC build configuration and code. The code in GCC that utilizes pthread_key_create marks it as extern and weak, which is different from what is in pthread.h. And the reason for that, as commented in the libgcc code, is so that pthread_key_create is weak, which leads libggc.so.1 not having a run time dependency on libpthread.so.0. Tom -- You are receiving this mail because: You are on the CC list for the bug.
