[Bug ld/15889] New: Follow microsoft convention for naming of __stdcall function in PE-Export table
http://sourceware.org/bugzilla/show_bug.cgi?id=15889
Bug ID: 15889
Summary: Follow microsoft convention for naming of __stdcall
function in PE-Export table
Product: binutils
Version: 2.23
Status: NEW
Severity: enhancement
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: sven.koehler at gmail dot com
When creating shared libraries (i.e. DLLs) using mingw-w64 or mingw32
toolchains, the names of functions in the PE-Export table of the DLL differs
from the naming convention that the microsoft linker follows. Consider the
following example:
Compile the source code
#define EXPORT __declspec(dllexport)
EXPORT int __cdecl fooC(int x) { return x; }
EXPORT int __stdcall fooStd(int x) { return x; }
EXPORT int __fastcall fooFast(int x) { return x; }
with the command
i686-w64-mingw32-gcc -shared -o export.dll export.c
According to i686-w64-mingw32-objdump -x export.dll, the export table looks
like this:
Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 14d2 Export RVA
[ 1] +base[ 2] 14c0 Export RVA
[ 2] +base[ 3] 14c8 Export RVA
[Ordinal/Name Pointer] Table
[ 0] @fooFast@4
[ 1] fooC
[ 2] fooStd@4
However, create a DLL from the same source with microsoft tools would yield the
following export table:
Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 14d2 Export RVA
[ 1] +base[ 2] 14c0 Export RVA
[ 2] +base[ 3] 14c8 Export RVA
[Ordinal/Name Pointer] Table
[ 0] @fooFast@4
[ 1] fooC
[ 2] _fooStd@4
The only different is the underscore, which ld removes, but microsoft linker
does not remove. The different behaviour is well known (see
http://wyw.dcweb.cn/stdcall.htm for example) and workarounds like the --kill-at
switch have been introduced. Note that the names in the export table for
__cdecl and __fastcall calling conventions are identical in both cases.
It seems that __stdcall is a calling convention frequently used when writing
DLLs. The different naming conventions in the export table cause trouble in
scenarios where a DLL but is not intended to be linked into an application
using an import lib, but is to be a "plug-in" to some other application which
uses LoadLibrary and GetProcAddress. Such may expect the names in the export
table to follow the microsoft conventions. In my case, the application is a JVM
and my DLL is a JNI library. Also, the --kill-at workaround works for me.
However, it is not clear to my why the naming-conventions have never been
adjusted to follow microsoft's design more closely. Doing so would be very
convenient to users. Thus I'd hereby like to make that request.
To the best of my knowledge this change will not effect any users that link
using import libs and should thus not have any serious side-effects.
--
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/15889] Follow microsoft convention for naming of __stdcall function in PE-Export table
http://sourceware.org/bugzilla/show_bug.cgi?id=15889 Sven changed: What|Removed |Added Target||i686-w64-mingw32 Host||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/15889] Don't remove leading underscore of __stdcall functions in PE export table
https://sourceware.org/bugzilla/show_bug.cgi?id=15889 Sven changed: What|Removed |Added Summary|Follow microsoft convention |Don't remove leading |for naming of __stdcall |underscore of __stdcall |function in PE-Export table |functions in PE export ||table -- 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/18173] New: Output Section LMA Alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=18173
Bug ID: 18173
Summary: Output Section LMA Alignment
Product: binutils
Version: 2.25
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: sven.koehler at gmail dot com
With a linker script, it is currently not possible to specify the alignment of
the LMA of an output section. Consider the following example:
.data : ALIGN(8) {
...
} >RAM AT>ROM
That will align the VMA of the section on a 8byte boundary, regardless of
alignment of the input sections (which could be less) but not the LMA.
Then we have ALIGN_WITH_INPUT, which cannot be combined with ALIGN(x). It will
align the VMA to the alignment of the input section (which may be less than 8)
and will increase the LMA by the same amount that the VMA was increased to
achieve the alignment. There are two problem:
(1) If the misalignment of VMA and LMA was different, we still end up with an
unaligned LMA.
(2) Even if VMA and LMA are equally misaligned, then there is no way to have a
minimum alignment of, as there is no way to combine ALIGN_WITH_INPUT with
ALIGN(8)
On some platforms however, such as ARM, it is somewhat important to have both
VMA and LMA aligned to a certain boundary to efficiently copy the section from
LMA to VMA. As shown above, ALIGN(x) and ALIGN_WITH_INPUT don't help.
What would help:
(1) If the misalignment of VMA and LMA could be assumed to be equal, then
ALIGN(x) in combination with ALIGN_WITH_INPUT would help.
But I have to say that the name of ALIGN_WITH_INPUT is a bit misleading, as
it's actually about keeping padding between VMA and LMA equal. Also, unlike
ALIGN(x), ALIGN_WITH_INPUT is actually about the LMA, not the VMA.
(2) Add something like ALIGNLMA(x) in addition to ALIGN(x), where the former is
about LMA alignment and the latter is about VMA alignment.
--
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/18174] New: Improve documentation on Forced Output Section Alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=18174 Bug ID: 18174 Summary: Improve documentation on Forced Output Section Alignment Product: binutils Version: 2.25 Status: NEW Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: sven.koehler at gmail dot com I'm referring to https://sourceware.org/binutils/docs-2.25/ld/Forced-Output-Alignment.html The documentation given there is insufficient. An Output Section has two addresses, the LMA and the VMA. It should be made clear ALIGN(x) effects the VMA, and the VMA only. I believe, this might have been different in earlier versions of binutils, where the LMA was also affected. If so, that should be documented as well. The effect of ALIGN(x) on VMA and LMA can currently only be understood by intense testing. Also, ALIGN_WITH_INPUT keeps the difference between LMA and VMA intact, as the documentation states. But again without a lot of testing, it's not clear what's going on. It would be better to describe ALIGN_WITH_INPUT in a way that makes clear what the effect on VMA and LMA is: 1) the VMA is aligned in the usual way (to the strictest alignment of the input sections) 2) the LMA is not aligned, but instead padded (!) with the same amount that added to the VMA to achieve the section's VMA alignment. -- 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/30444] New: Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 Bug ID: 30444 Summary: Implementation of COFF/PE format lacks base64 support (Extended COFF Object) Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sven.koehler at gmail dot com Target Milestone: --- Created attachment 14879 --> https://sourceware.org/bugzilla/attachment.cgi?id=14879&action=edit 7z archive will all the files needed Find attached a *.c file that contains the declaration of 8 variables. Each variable has a name with more than 128 characters. So the size of the string table is larger than 80 * 128 = 10.240.000. It turns out, that section names longer than 8 bytes will be encoded with a slash followed by an offset into the string table. The offset will be encoded in decimal. Offsets larger than 9.999.999 cannot be encoded (slash followed by 7 decimal digits) since the buffer for the section name has length 8. LLVM encodes large offsets by using two slashes followed by a base64 encoding of a 32bit integer. This encoding is not understood by binutils: ld, objdump, and possibly other tools don't decode such section names. Instead they print lots of warnings and linking eventually fails with an error "multiple definition of ..." because COMDAT sections are not properly eliminated. An example for such a warning is: > x86_64-w64-mingw32-objdump: test-llvm.o: warning: COMDAT symbol > '.bss$10' > does not match section name '//AAph7S' I have confirmed, that microsoft's dumpbin.exe (equivalent of objdump) understands base64 encoded section names. So base64 encoding seems to be supported by Microsoft toolchains. However, I was not able to find documentation on this. dumpbin calls such files "EXTENDED COFF OBJECT" while files without base64 encoding are called just "COFF OBJECT". LLVM's tools (such as lld and llvm-objdump) properly handle base64 section names as well. While binutils fails to read such files, the assembler also fails to write such files. In particular, compiling the attached *.c file with gcc just results in an error message "File too big". Find attached the archive test.7z with the following files: > test.c > test-llvm.o > test-llvm.o.dumpbin > test-llvm.o.objdump Steps to reproduce: > clang -fdata-sections -target x86_64-w64-mingw32 -c test.c -o test-llvm.o > x86_64-w64-mingw32-objdump -x test-llvm.o >test-llvm.o.objdump 2>&1 > dumpbin.exe /out:test-llvm.o.dumpbin /headers test-llvm.o > x86_64-w64-mingw32-gcc -fdata-sections -c test.c -o test-gcc.o See test-llvm.o.objdump for the warnings by objdump. The gcc command gives you the "file too big" error. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #2 from Sven --- //AAph7S is an example of a section name from the attached file. The part after the two slashed decodes to the byte sequence 00 0a 61 ed. So i'm pretty sure, the byte order is big endian. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #4 from Sven --- As I wrote, I did not find any specification. This seems to be related: https://reviews.llvm.org/D118692 LLVM's COFF/Writer.cpp might be a good start. I haven't looked into those, yet. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #5 from Sven --- This is the PE format specification by Microsoft: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format It does not mention base64. It only mentions the decimal integer encoding with one preceding slash. But as I wrote above, base64 is definitely supported by Microsoft's tools. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #8 from Sven --- (In reply to Jose E. Marchesi from comment #7) > While implementing this in GNU poke [1] I noticed that the base64 value > encoded in ASCII after the // is mutilated, since in order to fit in six > characters it is omitting the trailing two padding characters ==. Yes, the padding is omitted. But according to section 3.2 of RFC 4648, the padding is optional if so desired. Any RFC compliant decoder should work. Also see https://en.wikipedia.org/wiki/Base64#Variants_summary_table -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #10 from Sven --- Created attachment 14883 --> https://sourceware.org/bugzilla/attachment.cgi?id=14883&action=edit assembly file generated from test.c with x86_64-w64-mingw32-gcc (In reply to Jose E. Marchesi from comment #9) > Sven, could you please provide: > > 1) A test.S compiled from test.c. I have a x86_64-w64-mingw binutils built > but not a suitable cross GCC. I will then derive testcases for binutils > starting from that file. Find attached the file test-gcc.s (compressed with xz). It was generated with the command x86_64-w64-mingw32-gcc -fdata-sections -S test.c -o test-gcc.s If you use x86_64-w64-mingw32-as, it will give you the "file too big" error message. > 2) A test.o built with a toolchain that is able to emit //BASE64 names. I > am starting with the BFD support for reading the names. Then will implement > writing support. Please clarify. I already uploaded test-llvm.o. It contains plenty of //BASE64 names. Currently llvm is currently the only toolchain that allows me to create such a file. Is that sufficient? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #13 from Sven --- (In reply to Jose E. Marchesi from comment #12) > Ok, this is worse than I thought :) > > Given the section name //AAph7S, the corresponding base64 to decode is > 00AAph7S, _not_ AAph7S==. > > Found it the hard way while implementing this in BFD. I think you mean ph7S, because in base64 the zero digit is A. They probably replaced decimal digits with base64 digits. They did not apply standard base64 to the binary representation of a 32bit integer. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #15 from Sven --- (In reply to Sven from comment #2) > //AAph7S is an example of a section name from the attached file. The part > after the two slashed decodes to the byte sequence 00 0a 61 ed. So i'm > pretty sure, the byte order is big endian. Given the new results, I should mention that I was wrong an //AAph7S decodes to 0xa61ed2. In test-llvm.o, there are also //base64 examples that end in a slash, which would not happen when encoding 32bit with RFC base64. For example //AAoQj/ decodes to 0xa108ff. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #16 from Sven --- If you have something to review or test, let me know -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 Sven changed: What|Removed |Added CC||sven.koehler at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Sven changed: What|Removed |Added CC||sven.koehler at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/12634] New: improve objdump's way of showing non-executable sections
http://sourceware.org/bugzilla/show_bug.cgi?id=12634 Summary: improve objdump's way of showing non-executable sections Product: binutils Version: 2.21 Status: NEW Severity: enhancement Priority: P2 Component: binutils AssignedTo: unassig...@sources.redhat.com ReportedBy: sven.koeh...@gmail.com Hi, as far as I can see, objdump currently has two ways of showing non-executable section: using -D, it shows labels, but it tries to disassemble the data using -s, it shows non-executable section as one big BLOB of data I'd like to suggest a third mode: In this mode, binutils should behave almost like -D, that it objdump shows the labels/symbols, prints the binary data, but instead of showing a disssembly of the data, it should show some ASCII-like representation of the binary data (very much like most hex-editors do it). -- 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 http://lists.gnu.org/mailman/listinfo/bug-binutils
