[Bug ld/30004] New: LD --exclude-all-symbols generates export table
https://sourceware.org/bugzilla/show_bug.cgi?id=30004
Bug ID: 30004
Summary: LD --exclude-all-symbols generates export table
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
LD --exclude-all-symbols has issues for Native PE executables. It causes
generation of empty export table and puts name of the output executable/driver
(-o) as name of the export library. PE executables which are in shared address
space (e.g. NT driver executables) should really do not be treated as libraries
with library name (unless explicitly asked for such thing).
Test case on Debian Sid:
$ x86_64-w64-mingw32-ld -v
GNU ld (GNU Binutils) 2.39.90.20230110
$
$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/12-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr
--includedir='/usr/include' --mandir='/usr/share/man'
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu'
--disable-maintainer-mode --disable-dependency-tracking --prefix=/usr
--enable-shared --enable-static --disable-multilib --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib
--enable-libstdcxx-time=yes --with-tune=generic --with-headers
--enable-version-specific-runtime-libs --enable-fully-dynamic-string
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto
--enable-threads=win32 --program-suffix=-win32
--program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32
--with-as=/usr/bin/x86_64-w64-mingw32-as
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic
--enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking SED=/bin/sed
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 12-win32 (GCC)
$
$ cat test-exclude-all-symbols.c
int empty(void) { return 0; }
$
$ x86_64-w64-mingw32-gcc test-exclude-all-symbols.c -pie -nostdlib -e empty
-Wl,--subsystem,native -Wl,--exclude-all-symbols -o
test-exclude-all-symbols.sys
$
$ x86_64-w64-mingw32-objdump -p test-exclude-all-symbols.sys | grep -A 20
'There is an export table'
There is an export table in .edata at 0x140005000
The Export Tables (interpreted .edata section contents)
Export Flags0
Time/Date stamp 63c4107f
Major/Minor 0/0
Name5028 test-exclude-all-symbols.sys
Ordinal Base1
Number in:
Export Address Table
[Name Pointer/Ordinal] Table
Table Addresses
Export Address Table5028
Name Pointer Table 5028
Ordinal Table 5028
Export Address Table -- Ordinal Base 1
[Ordinal/Name Pointer] Table
$
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30005] New: __declspec(code_seg("segname")) does not work
https://sourceware.org/bugzilla/show_bug.cgi?id=30005
Bug ID: 30005
Summary: __declspec(code_seg("segname")) does not work
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
GCC/LD does not support __declspec(code_seg("segname")) declarator for
specifying name of PE/COFF segment name.
Instead GCC/LD supports different and custom syntax
__declspec(section("segname")) incompatible with other compilers, like MSVC.
Please add support for de-facto standard "code_seg" declarator into the PE/COFF
__declspec keyword and not custom declarator. It does not bring any value, just
make code incompatible with gcc.
Test case on Debian sid:
$ x86_64-w64-mingw32-ld -v
GNU ld (GNU Binutils) 2.39.90.20230110
$
$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/12-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr
--includedir='/usr/include' --mandir='/usr/share/man'
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu'
--disable-maintainer-mode --disable-dependency-tracking --prefix=/usr
--enable-shared --enable-static --disable-multilib --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib
--enable-libstdcxx-time=yes --with-tune=generic --with-headers
--enable-version-specific-runtime-libs --enable-fully-dynamic-string
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto
--enable-threads=win32 --program-suffix=-win32
--program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32
--with-as=/usr/bin/x86_64-w64-mingw32-as
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic
--enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking SED=/bin/sed
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 12-win32 (GCC)
$
$ cat test-code-seg.c
__declspec(code_seg("segname"))
int test(void) { return 0; }
$
$ x86_64-w64-mingw32-gcc -c test-code-seg.c -o test-code-seg.o
test-code-seg.c:2:1: warning: 'code_seg' attribute directive ignored
[-Wattributes]
2 | int test(void) { return 0; }
| ^~~
$
$ x86_64-w64-mingw32-objdump -h test-code-seg.o | grep segname
$
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30004] LD --exclude-all-symbols generates export table
https://sourceware.org/bugzilla/show_bug.cgi?id=30004 --- Comment #2 from Pali Rohár --- Hello! Sorry for a longer delay. Now I did tests with your proposed patch and export table and .edata section is not generated anymore. But there is one thing which I do not understand: Why when bfd_link_pic() is true is generated export table? Because for me it looks like that position independent code has nothing with export table. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30137] New: LD --dynamicbase does not generate relocation info
https://sourceware.org/bugzilla/show_bug.cgi?id=30137 Bug ID: 30137 Summary: LD --dynamicbase does not generate relocation info Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- LD --dynamicbase does not work correctly for PE executables. It does not generate relocation info. Without relocation info in PE binary, it is not possible to relocate base address. Which makes dynamic base non-working. Test case which calls external function "external()" from external.dll which needs to be relocated at runtime. $ x86_64-w64-mingw32-ld -v GNU ld (GNU Binutils) 2.40 $ cat external.def LIBRARY "external.dll" EXPORTS external $ cat test-dynamicbase.S .globl main main: call*__imp_external(%rip) mov $0, %rax ret $ x86_64-w64-mingw32-dlltool -d external.def -l external.dll.a $ x86_64-w64-mingw32-as test-dynamicbase.S -o test-dynamicbase.o $ x86_64-w64-mingw32-ld --dynamicbase test-dynamicbase.o external.dll.a -o test-dynamicbase.exe $ x86_64-w64-mingw32-objdump -f -p test-dynamicbase.exe | grep -i reloc HAS_RELOC, EXEC_P, HAS_SYMS, HAS_LOCALS, D_PAGED Entry 5 Base Relocation Directory [.reloc] As can be seen in objdump output, binary is marked with HAS_RELOC but .reloc section is completely empty. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30139] New: Incorrect ordinal numbers for aliased symbols in DEF file
https://sourceware.org/bugzilla/show_bug.cgi?id=30139
Bug ID: 30139
Summary: Incorrect ordinal numbers for aliased symbols in DEF
file
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
DEF file can contain alias for some symbol via == operator. But if such aliased
symbol is used in the code then binutils generates wrong ordinal symbol in PE
import table.
Below is simple example to demonstrate this issue.
Lets to have simple library library.dll.dll which has only one function "void
function(void)" under exported symbol "function" and also under exported
ordinal number 1. So DEF file for this library is:
LIBRARY "library.dll"
EXPORTS
function @1
If application wants to call this function() under name alias() then into DEF
file is added alias line:
alias == function
And using either to alias() or to function() would result in the same call.
But binutils/dlltool has issue and for alias() generates wrong ordinal number
and moreover generates two export symbols for function(). It can be seen in
objdump output.
$ x86_64-w64-mingw32-dlltool -V
GNU x86_64-w64-mingw32-dlltool (GNU Binutils) 2.39.90.20230110
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
$ cat library.def
LIBRARY "library.dll"
EXPORTS
function @1
alias == function
$ cat test-ordinal.c
__attribute__((dllimport)) void function(void);
__attribute__((dllimport)) void alias(void);
int main() {
function();
alias();
return 0;
}
$ x86_64-w64-mingw32-dlltool -d library.def -l library.dll.a
$ x86_64-w64-mingw32-gcc test-ordinal.c library.dll.a -o test-ordinal.exe
$ x86_64-w64-mingw32-objdump -p test-ordinal.exe | grep -A 4 library.dll
DLL Name: library.dll
vma: Hint/Ord Member-Name Bound-To
84e62 function
84f21 function
As can be seen in defined library.def file, in "library.dll" there is no symbol
with ordinal number 2 and symbol "function" has ordinal number 1.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30140] New: LD does not link PE executable with symbols from DEF file
https://sourceware.org/bugzilla/show_bug.cgi?id=30140
Bug ID: 30140
Summary: LD does not link PE executable with symbols from DEF
file
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
Lets take simple test-library.dll with one exported function "func1". And try
to use it in test-executable.c.
$ cat test-library.def
LIBRARY "test-library.dll"
EXPORTS
func1
$ cat test-executable.c
__attribute__((dllimport)) void func1(void);
int main() {
func1();
return 0;
}
If gcc is invoked directly with test-executable.c and test-library.def then LD
linker throws strange error and does not produce output executable file:
$ x86_64-w64-mingw32-gcc test-executable.c test-library.def -o
test-executable.exe
/usr/bin/x86_64-w64-mingw32-ld: cannot export func1: symbol not defined
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccx6dW5J.o:test-executabl:(.text+0x10):
undefined reference to `__imp_func1'
collect2: error: ld returned 1 exit status
If test-executable.c is linked with import library generated from
test-library.def then everything works fine and produce output executable file:
$ x86_64-w64-mingw32-dlltool -d test-library.def -l test-library.dll.a
$ x86_64-w64-mingw32-gcc test-executable.c test-library.dll.a -o
test-executable.exe
I think that this is an issue in LD because it should be able to handle DEF
file correctly. Or if LD does not support DEF files then it should throw
meaningful human readable error. Not that "symbol not defined" because it *is*
defined in test-library.def file.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30141] New: LD does not mark INIT section as IMAGE_SCN_MEM_DISCARDABLE
https://sourceware.org/bugzilla/show_bug.cgi?id=30141
Bug ID: 30141
Summary: LD does not mark INIT section as
IMAGE_SCN_MEM_DISCARDABLE
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
INIT code section is used in NT drivers (Native PE binaries) only during
initilization and section should be marked as discardable to not waste memory.
LD does not mark this section as discardable.
Test case: Very simple NT kernel driver with entry point which does nothing:
$ cat test-init.c
__attribute__((stdcall))
long DriverEntry(void *DriverObject, void *RegistryPath) asm("DriverEntry")
__attribute__((section("INIT")));
__attribute__((stdcall))
long DriverEntry(void *DriverObject, void *RegistryPath) {
return 0;
}
$ x86_64-w64-mingw32-gcc -nostartfiles -nodefaultlibs -nostdlib
-Wl,--subsystem,native -e DriverEntry test-init.c -o test-init.sys
$ readpe test-init.sys | grep -A 11 'Name:\s*INIT'
export directory not found
Name:INIT
Virtual Address: 0x2000
Physical Address:0x14
Size:0x200 (512 bytes)
Pointer To Data: 0x600
Relocations: 0
Characteristics: 0x60300020
Characteristic Names
IMAGE_SCN_CNT_CODE
IMAGE_SCN_MEM_EXECUTE
IMAGE_SCN_MEM_READ
Section
As can be seen in readpe output, INIT section is not marked as discardable
(IMAGE_SCN_MEM_DISCARDABLE). I'm not sure how to verify this with objdump as I
do not know how it shows IMAGE_SCN_* flags. So I used readpe for verification.
For NT kernel drivers same applies for .idata and .rsrc sections which should
be discardable too.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30142] New: PE .rsrc section is generated as writable
https://sourceware.org/bugzilla/show_bug.cgi?id=30142
Bug ID: 30142
Summary: PE .rsrc section is generated as writable
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
PE resources in .rsrc section should be read-only but LD/windres generates them
as read-write. Simple test case:
$ cat empty.c
void empty(void) {}
$ cat test-rsrc.rc
1 VERSIONINFO
BEGIN
END
$ x86_64-w64-mingw32-windres --input-format=rc --output-format=coff
--input=test-rsrc.rc --output=test-rsrc.o
$ x86_64-w64-mingw32-gcc -nostartfiles -e empty empty.c test-rsrc.o -o
test-rsrc.exe
$ readpe test-rsrc.exe | grep -A 11 'Name:\s*\.rsrc'
export directory not found
Name:.rsrc
Virtual Address: 0x6000
Physical Address:0xb8
Size:0x200 (512 bytes)
Pointer To Data: 0xe00
Relocations: 0
Characteristics: 0xc040
Characteristic Names
IMAGE_SCN_CNT_INITIALIZED_DATA
IMAGE_SCN_MEM_READ
IMAGE_SCN_MEM_WRITE
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30143] New: All PE sections are paged
https://sourceware.org/bugzilla/show_bug.cgi?id=30143
Bug ID: 30143
Summary: All PE sections are paged
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
GCC/LD for NT kernel drivers marks all functions as paged, including those
which should not be paged. Driver functions which could be paged are those
which are in PE section PAGE. Section which must not be paged must be marked
with IMAGE_SCN_MEM_NOT_PAGED flag.
For a test case here is simple NT kernel driver which entry point function is
in standard INIT non-paged section, driver unload function is explicitly put
into PAGE section (so it can be paged) and dispatch create function is in
default .text section which should be also non-paged.
$ cat test-paging.c
#include
static NTSTATUS NTAPI DriverDispatchCreate(IN PDEVICE_OBJECT DeviceObject, IN
PIRP Irp) {
Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}
__attribute__((section("PAGE")))
static VOID NTAPI DriverUnload(IN PDRIVER_OBJECT DriverObject) {
}
NTSTATUS NTAPI DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING
RegistryPath) asm("DriverEntry") __attribute__((section("INIT")));
NTSTATUS NTAPI DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING
RegistryPath) {
DriverObject->DriverUnload = DriverUnload;
DriverObject->MajorFunction[IRP_MJ_CREATE] = DriverDispatchCreate;
return 0;
}
$ x86_64-w64-mingw32-gcc -nostartfiles -nodefaultlibs -nostdlib
-Wl,--subsystem,native -e DriverEntry `x86_64-w64-mingw32-gcc -E -Wp,-v -o
/dev/null - 2>&1
[Bug ld/30144] New: LD --entry does not accept function name
https://sourceware.org/bugzilla/show_bug.cgi?id=30144
Bug ID: 30144
Summary: LD --entry does not accept function name
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
NT kernel drivers have as entry point function DriverEntry with stdcall calling
convension. Compiling NT kernel drivers via GCC/LD would be lot of easier if LD
supports specifying entry point as function name as opposite of the mangled
symbol name, which is DriverEntry for AMD64 and _DriverEntry@8 for IX86.
$ cat test-entry.c
__attribute__((stdcall))
long DriverEntry(void *DriverObject, void *RegistryPath) {
return 0;
}
$ x86_64-w64-mingw32-gcc -nostartfiles -nodefaultlibs -nostdlib
-Wl,--subsystem,native -Wl,--entry=DriverEntry test-entry.c -o test-entry.sys
(compiles fine, no warning/error)
$ i686-w64-mingw32-gcc -nostartfiles -nodefaultlibs -nostdlib
-Wl,--subsystem,native -Wl,--entry=DriverEntry test-entry.c -o test-entry.sys
/usr/bin/i686-w64-mingw32-ld: warning: cannot find entry symbol DriverEntry;
defaulting to 00401000
(entry point is completely ignored and replaced by some random address)
$ i686-w64-mingw32-gcc -nostartfiles -nodefaultlibs -nostdlib
-Wl,--subsystem,native -Wl,--entry=_DriverEntry@8 test-entry.c -o
test-entry.sys
(compiles fine, no warning/error)
As can be seen in the above example, for every architecture it is needed to
pass correctly mangled symbol name into LD --entry argument. It would really
help if LD tries to represent --entry argument as function name and mangle it
to guess symbol name. As currently it is not possible to specify compile
parameters which would work for all architectures universally.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30145] New: No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 Bug ID: 30145 Summary: No way to specify PE IMAGE_SCN_* characteristics Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- In some cases, mostly for debugging purposes, it is needed to change or overwrite default PE section characteristics (IMAGE_SCN_* flags). But after reading gcc, ld and objcopy documentation, I did not find any way how to achieve it. Microsoft linker link.exe allows to specify custom characteristics via /SECTION: command line option. Something like this should be supported by ld and objcopy. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30137] LD --dynamicbase does not generate relocation info
https://sourceware.org/bugzilla/show_bug.cgi?id=30137 --- Comment #2 from Pali Rohár --- But it does not generate relocation information for the call example in the bug description. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30137] LD --dynamicbase does not generate relocation info
https://sourceware.org/bugzilla/show_bug.cgi?id=30137 --- Comment #3 from Pali Rohár --- Ou, my bad. I totally forgot that I wrote example for AMD64 and AMD64 does not use relocation for indirect calls. Only 32-bit x86 needs it. IX86 example is: $ cat test-dynamicbase.S .globl _main _main: call*__imp__external mov $0, %eax leave ret $ i686-w64-mingw32-dlltool -d external.def -l external.dll.a $ i686-w64-mingw32-as test-dynamicbase.S -o test-dynamicbase.o $ i686-w64-mingw32-ld --dynamicbase test-dynamicbase.o external.dll.a -o test-dynamicbase.exe $ i686-w64-mingw32-objdump -f -p test-dynamicbase.exe | grep -i reloc HAS_RELOC, EXEC_P, HAS_SYMS, HAS_LOCALS, D_PAGED Entry 5 3000 000c Base Relocation Directory [.reloc] PE File Base Relocations (interpreted .reloc section contents) reloc0 offset2 [1002] HIGHLOW reloc1 offset0 [1000] ABSOLUTE $ i686-w64-mingw32-objdump -d test-dynamicbase.exe ... 401000: ff 15 30 20 40 00 call *0x402030 401006: b8 00 00 00 00 mov$0x0,%eax 40100b: c9 leave 40100c: c3 ret ... So for IX86 relocation information with LD 2.40 is correctly generated. When I tried those steps with LD 2.31 I got from objdump output: relocations stripped Entry 5 Base Relocation Directory [.reloc] So the issue is already fixed. Sorry for the noise and wrong example (AMD64 vs IX86). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30005] __declspec(code_seg("segname")) does not work
https://sourceware.org/bugzilla/show_bug.cgi?id=30005 --- Comment #2 from Pali Rohár --- Reported to gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30147] New: Allow to specify PE export name
https://sourceware.org/bugzilla/show_bug.cgi?id=30147 Bug ID: 30147 Summary: Allow to specify PE export name Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- When generating ELF binary it is possible to specify its export name by -soname= option, and this option is working fine ELF. But seems there is no way to specify export name when generating PE binary. LD accepts -soname= option also for PE binaries but seems that it is just ignored without any warning/error message. And PE export name in export table (.edata) is taken from the -o output option. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30004] LD --exclude-all-symbols generates export table
https://sourceware.org/bugzilla/show_bug.cgi?id=30004 --- Comment #5 from Pali Rohár --- Thanks! Anyway, the whole issue is about executables, not libraries. So I still do not understand reasons. And I'm not quite sure what it is "position independent DLL". Every DLL library should contain relocation info to allow library "rebase" to different address, which is de-facto position independent code. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30147] Allow to specify PE export name
https://sourceware.org/bugzilla/show_bug.cgi?id=30147 --- Comment #2 from Pali Rohár --- It is quite annoying if for different platforms it is needed to use different command line options or different config files to specify some option, like setting export name. It makes build systems, scripts, etc... which compiles multiplatform applications / libraries via gcc/ld more complicated. Would not it be better to have one common option which sets export name for both ELF and PE targets (and possible other supported by binutils)? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30004] LD --exclude-all-symbols generates export table
https://sourceware.org/bugzilla/show_bug.cgi?id=30004 --- Comment #6 from Pali Rohár --- Hm... When I'm thinking about it, DLL library without export table does not make sense (or yes?). So maybe condition for generating export table when there is no exported symbol should have been based on the fact if building library or executable (instead of on --exclude-all-symbols or link_pic)? Somebody should look at this issue properly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30300] New: LTO drops entry point symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=30300
Bug ID: 30300
Summary: LTO drops entry point symbol
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
Originally reported on: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109368
LTO for PE executables drops entry point symbol when the default entry point is
used. There is no warning and just PE AddressOfEntryPoint is zeroed. Which
results in broken PE binary.
When non-default entry point is used and specified via -e option then LTO does
not drop entry point symbol and generates working PE executable.
Simple test case which does not use any system library or startup file:
$ cat test-nostartfiles.c
int mainCRTStartup(void) { return 0; }
Default console binary has entry point mainCRTStartup() function (as hardcoded
in LD sources).
$ i686-w64-mingw32-gcc -Wall -Wextra -nostartfiles -nodefaultlibs -nostdlib
test-nostartfiles.c -o test-nostartfiles.exe
Without LTO it generates working PE binary which correctly returns 0 to system.
It also has correct AddressOfEntryPoint field in PE:
$ i686-w64-mingw32-objdump -p test-nostartfiles.exe | grep AddressOfEntryPoint
AddressOfEntryPoint 1000
When compiling with LTO it does not throw any warning but generates broken PE
binary:
$ i686-w64-mingw32-gcc -Wall -Wextra -nostartfiles -nodefaultlibs -nostdlib
test-nostartfiles.c -o test-nostartfiles.exe -flto
Trying to run it, it crashes and has zeroed AddressOfEntryPoint:
$ i686-w64-mingw32-objdump -p test-nostartfiles.exe | grep AddressOfEntryPoint
AddressOfEntryPoint
When non-default entry point is used (specified via -e option) then LTO works
correctly and does not drop its entry point.
$ cat test-nostartfiles2.c
int my_entry(void) { return 0; }
$ i686-w64-mingw32-gcc -Wall -Wextra -nostartfiles -nodefaultlibs -nostdlib -e
_my_entry test-nostartfiles2.c -o test-nostartfiles2.exe -flto
$ i686-w64-mingw32-objdump -p test-nostartfiles2.exe | grep AddressOfEntryPoint
AddressOfEntryPoint 1000
Compiled binary works fine.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30139] Incorrect ordinal numbers for aliased symbols in DEF file
https://sourceware.org/bugzilla/show_bug.cgi?id=30139 --- Comment #1 from Pali Rohár --- Also see that linker generates two entries for one exported function in import table. For exported function is one entry in import table enough. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30144] LD --entry does not accept function name
https://sourceware.org/bugzilla/show_bug.cgi?id=30144
--- Comment #2 from Pali Rohár ---
As a workaround I have already come up with this:
__attribute__((stdcall)) long DriverEntry(void *DriverObject, void
*RegistryPath) asm("DriverEntry");
__attribute__((stdcall)) long DriverEntry(void *DriverObject, void
*RegistryPath) {
return 0;
}
And then you can use -Wl,--entry=DriverEntry for both AMD64 and IX86 archs.
Via asm keyword in function declaration you can specify symbol name of the
function itself.
And because entry point symbol is basically used only by linker for filling
base address field in PE binary, it can be anything.
But this is still a workaround because it is not practical to add #ifdef for
GNU tools into source code. Specially when MS tools do not need any special
arch dependent command line switch or #ifdef. Switch /ENTRY:DriverEntry works
for both AMD64 and IX86.
I thought that it could be relatively easy for PE IX86 version of LD to search
for symbol _XYZ@number when symbol XYZ specified in --entry does not exist.
Specially because there is some logic related to this (--kill-at). But I have
not looked at source code, so this was just my speculation...
Another option would be to implement switch to instruct gcc (or ld) to "compile
NT kernel driver" (I created issue for it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108852) and part of it for IX86
platform could be automatic passing of --entry=_DriverEntry@8.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #2 from Pali Rohár --- In past I have tried to use objcopy --set-section-flags but it did not work, I did not get expected result and I do not remember exact details. As you mentioned this option, I will try it again with new binutils version and let you know what are the results, including test cases (for reproducibility in future). For sure objcopy should support changing PE section characteristics. As objcopy is commonly used for changing / extracting sections of object files or executables. Ability to specify it directly in linker would be useful, but well, for sure you know better if it is hard to implement it and what can be impact on (new?) bugs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30143] All PE sections are paged
https://sourceware.org/bugzilla/show_bug.cgi?id=30143 --- Comment #2 from Pali Rohár --- Hello! I'm replying below as inline comments. (In reply to Nick Clifton from comment #1) > Hi Pali, > > OK, so I am assuming that the desired behaviour is specific to the NT > kernel. > Ie, the default of allowing all sections to be paged is correct for most PE > binaries, just not the kernel ? Yes, this issue is about NT kernel drivers. For NT user PE executables is current behavior correct. > Given that, there needs to be some way to distinguish between building a > kernel > and building a normal binary and the most obvious way is to have a custom > linker script for the kernel. This script can set the > IMAGE_SCN_MEM_NOT_PAGED > flag for all sections except one called "PAGE". Do you agree ? For sure distinguish between NT kernel driver executables and PE user executables is needed. And what kind of solution for this is used (custom linker script, compile switch, ...) I will let to you / binutils developers. I think that this depends on architecture of the whole project and I do not think that I see what is the best choice here. Linker script is being specified by the command line option, so if this new linker script would be as part of the "standard" PE binutils installation then for user/developer perspective it is same as the "command line switch" way. > So what we need is a way to set PE specific section flags in linker > scripts. > (Which goes against what I said for PR 30145, but I am going through these > PRs in reverse order and I now see that there is a genuine need to extend > the linker script syntax). Ok. I know what whole picture is not simple, so I would expect that the final solution can be changed in time / during development. > The linker currently supports setting a section's type via the "TYPE=xxx" > syntax, but that is not quite what we need, since presumably there might > be a need to set more than one flag. So I guess that we need to add a > "FLAG=xxx[|xxx]+" syntax. Then, since the flags are going to be file > format/architecture specific, we need to implement a callback into the > linker's emulation framework in order to parse the flags, and another one > to set them. Plus we need to add support for the NOT_PAGED flag to the > BFD library (since it currently does not support it at all). *sigh* I > was right about this being a big potential source for new bugs. > > It would be a lot easier to just use objcopy to set the flag after the > the link has completed... In past I have already tried to use objcopy for setting those flags, but whatever I did was not able. Not sure if there is missing documentation for it, or it is really not supported (as I created an issue for it). But my current usage is to compile code, link object files to binary and then post-process this binary to fix these flags via my custom tool. Replacing my custom tool by standard objcopy tool is a step forward. >From "user" perspective, it would be better to allow specifying these flags directly into linker. > Any thoughts ? > > Cheers > Nick Another idea: What about extending GNU AS to allow setting these flags into COFF object file? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30140] LD does not link PE executable with symbols from DEF file
https://sourceware.org/bugzilla/show_bug.cgi?id=30140 --- Comment #3 from Pali Rohár --- Thank you for information. I see that it is quite misleading because DEF file in some case is used for "dllimport" functionality and in some other cases is used for "dllexport" functionality. And this can be even more confusing when building DLL library because it can do both things: import external symbols and export its own symbols. Eric Botcazou: It is quite pity that this is not supported, because more or less DEF file is text description of the binary import library, which is used for indirect linking. Direct linking with DLL file is nice feature but unusable for Windows system libraries (as they are not re-distributable and hence not part of any toolchain). I see benefit of usage of text files compared to binary. But I understand that you do not want to support or implement another option for linking. In the example from the issue description, I invoked gcc for building PE executable (and not DLL library). And if DEF file passed to gcc specify "dllexport" stuff, meaning which functions will be exported from _currently building DLL library_ as specified in LIBRARY keyword in DEF file, then I have feeling that this combination of command line options passed to gcc does not make sense, and gcc or ld should throw compile or link error. For example: Error: Compiling executable (because -shared nor -dll was not passed to gcc) but passed DEF file contains LIBRARY keyword suitable when compiling DLL library. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30147] Allow to specify PE export name
https://sourceware.org/bugzilla/show_bug.cgi?id=30147 --- Comment #3 from Pali Rohár --- I have tested that it is really possible to set export name via DEF file when generating PE binary. Export name can be specified via LIBRARY or via NAME keyword. At least I would suggest to extend -soname= documentation and mention there this information how to set PE export name. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30343] New: LTO drops explicitly referenced symbol _pei386_runtime_relocator
https://sourceware.org/bugzilla/show_bug.cgi?id=30343
Bug ID: 30343
Summary: LTO drops explicitly referenced symbol
_pei386_runtime_relocator
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
Originally reported on: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369
Points from discussion:
* OTOH if the linker(?) introduces such use then it should properly communicate
this via the resolution info. That would hint at a binutils bug.
* Yes, ld should claim _pei386_runtime_relocator (even if later it becomes
unneeded due to zero relocations left to fix up) to make this work properly.
That's for Binutils to fix on their side.
Original description:
When PE runtime-pseudo-reloc is used (e.g. referencing member of global array
from DLL library without being marked as dllimport), LTO drops
_pei386_runtime_relocator symbol even when it is explicitly referenced from
used symbol and then it complains that _pei386_runtime_relocator symbol was
dropped.
This is a bug because LTO compiler 1) should not drop any symbol which is
explicitly referenced from some used symbol and 2) should not drop special
_pei386_runtime_relocator symbol when it detected that PE runtime-pseudo-reloc
is used.
Test case:
Create simple DLL library with global array arr[]:
$ cat arr.c
int arr[2] = { 1, 2 };
$ i686-w64-mingw32-gcc -shared arr.c -o arr.dll
Define simple startup file for mingw (so to compile full test case without
mingw). Function _pei386_runtime_relocator() is explicitly referenced from the
startup function mainCRTStartup():
$ cat startup.c
extern void _pei386_runtime_relocator(void);
extern int main();
int __main() { }
__attribute__((force_align_arg_pointer))
__attribute__((noinline))
static int _mainCRTStartup(void) {
_pei386_runtime_relocator();
return main();
}
__attribute__((used)) /* required due to bug 109368 */
int mainCRTStartup(void) {
return _mainCRTStartup();
}
Implement PE runtime-pseudo-reloc. For compile-only purposes (without runtime
tests) it can be empty:
$ cat pseudo-reloc.c
void _pei386_runtime_relocator(void) { }
And finally simple test program which uses global array from DLL library which
is not explicitly marked with dllimport.
$ cat main.c
extern int arr[];
int main() {
return arr[1];
}
Without LTO this example compiles fine:
$ i686-w64-mingw32-gcc -Os -nostartfiles -nodefaultlibs -nostdlib startup.c
pseudo-reloc.c main.c arr.dll -o test.exe
With LTO enabled this example does not compile due to dropping explicitly
referenced symbol:
$ i686-w64-mingw32-gcc -Os -nostartfiles -nodefaultlibs -nostdlib startup.c
pseudo-reloc.c main.c arr.dll -o test.exe -flto
`__pei386_runtime_relocator' referenced in section `.rdata' of
test_exe_ertr04.o: defined in discarded section `.text' of /tmp/ccDpfRvt.o
(symbol from plugin)
collect2: error: ld returned 1 exit status
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30142] PE .rsrc section is generated as writable
https://sourceware.org/bugzilla/show_bug.cgi?id=30142 --- Comment #2 from Pali Rohár --- Hello! Thanks, I have tested this change and it works perfectly: $ readpe test-rsrc.exe | grep -A 11 'Name:\s*\.rsrc' export directory not found Name:.rsrc Virtual Address: 0x6000 Physical Address:0xb8 Size:0x200 (512 bytes) Pointer To Data: 0xe00 Relocations: 0 Characteristics: 0x4040 Characteristic Names IMAGE_SCN_CNT_INITIALIZED_DATA IMAGE_SCN_MEM_READ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30300] LTO drops entry point symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=30300 --- Comment #2 from Pali Rohár --- Hello! Patch is working fine: $ x86_64-w64-mingw32-gcc -Wall -Wextra -nostartfiles -nodefaultlibs -nostdlib test-nostartfiles.c -o test-nostartfiles.exe -flto $ x86_64-w64-mingw32-objdump -p test-nostartfiles.exe | grep AddressOfEntryPoint AddressOfEntryPoint 1000 $ x86_64-w64-mingw32-objdump -d test-nostartfiles.exe | head -18 test-nostartfiles2.exe: formát súboru pei-x86-64 Rozloženie sekcie .text: 000140001000 : 140001000: 55 push %rbp 140001001: 48 89 e5mov%rsp,%rbp 140001004: b8 00 00 00 00 mov$0x0,%eax 140001009: 5d pop%rbp 14000100a: c3 retq 14000100b: 90 nop 14000100c: 90 nop 14000100d: 90 nop 14000100e: 90 nop 14000100f: 90 nop -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145
--- Comment #3 from Pali Rohár ---
Ok, I have tested objcopy --set-section-flags on PE executable. Seems that it
is doing something, but only for some of the flags and I really do not
understand what it is doing. For me it looks like that objcopy
--set-section-flags sets random IMAGE_SCN_* characteristics...
Here is my test case and output from readpe after setting every flag via
objcopy --set-section-flags on simple PE executable with custom section
my_sect:
$ cat test-section-flags.c
__attribute__((section("my_sect"))) int val = 10;
int my_entry(void) { return val; }
$ x86_64-w64-mingw32-gcc -Wall -Wextra -nostartfiles -nodefaultlibs -nostdlib
-e my_entry test-section-flags.c -o test-section-flags.exe
$ readpe test-section-flags.exe 2>/dev/null | grep -A 11 my_sect
Name:my_sect
Virtual Size:0x4 (4 bytes)
Virtual Address: 0x2000
Size Of Raw Data:0x200 (512 bytes)
Pointer To Raw Data: 0x600
Number Of Relocations: 0
Characteristics: 0xc040
Characteristic Names
IMAGE_SCN_CNT_INITIALIZED_DATA
IMAGE_SCN_MEM_READ
IMAGE_SCN_MEM_WRITE
Section
$ for flag in alloc load noload readonly debug code data rom exclude share
contents merge strings; do echo "Flags: $flag"; x86_64-w64-mingw32-objcopy
--set-section-flags my_sect=$flag test-section-flags.exe
test-section-flags-new.exe && readpe test-section-flags-new.exe 2>/dev/null |
grep -A 12 my_sect; echo; done
Flags: alloc
Name:my_sect
Virtual Size:0x200 (512 bytes)
Virtual Address: 0x2000
Size Of Raw Data:0 (0 bytes)
Pointer To Raw Data: 0x600
Number Of Relocations: 0
Characteristics: 0xc080
Characteristic Names
IMAGE_SCN_CNT_UNINITIALIZED_DATA
IMAGE_SCN_MEM_READ
IMAGE_SCN_MEM_WRITE
Section
Name:.rdata
Flags: load
Name:my_sect
Virtual Size:0x4 (4 bytes)
Virtual Address: 0x2000
Size Of Raw Data:0x200 (512 bytes)
Pointer To Raw Data: 0x600
Number Of Relocations: 0
Characteristics: 0xc000
Characteristic Names
IMAGE_SCN_MEM_READ
IMAGE_SCN_MEM_WRITE
Section
Name:.rdata
Virtual Size:0x20 (32 bytes)
Flags: noload
Name:my_sect
Virtual Size:0x4 (4 bytes)
Virtual Address: 0x2000
Size Of Raw Data:0x200 (512 bytes)
Pointer To Raw Data: 0x600
Number Of Relocations: 0
Characteristics: 0xc200
Characteristic Names
IMAGE_SCN_MEM_DISCARDABLE
IMAGE_SCN_MEM_READ
IMAGE_SCN_MEM_WRITE
Section
Name:.rdata
Flags: readonly
Name:my_sect
Virtual Size:0x4 (4 bytes)
Virtual Address: 0x2000
Size Of Raw Data:0x200 (512 bytes)
Pointer To Raw Data: 0x600
Number Of Relocations: 0
Characteristics: 0x4000
Characteristic Names
IMAGE_SCN_MEM_READ
Section
Name:.rdata
Virtual Size:0x20 (32 bytes)
Virtual Address: 0x3000
Flags: debug
Name:my_sect
Virtual Size:0x4 (4 bytes)
Virtual Address: 0x2000
Size Of Raw Data:0x200 (512 bytes)
Pointer To Raw Data: 0x600
Number Of Relocations: 0
Characteristics: 0xc240
Characteristic Names
IMAGE_SCN_CNT_INITIALIZED_DATA
IMAGE_SCN_MEM_DISCARDABLE
IMAGE_SCN_MEM_READ
IMA
[Bug ld/30359] New: Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 Bug ID: 30359 Summary: Create Resource-Only DLL Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- Resource-Only DLL is windows PE binary of DLL type which does not contain any code, just resources in .rsrc section. See MS documentation for more details: https://learn.microsoft.com/en-us/cpp/build/creating-a-resource-only-dll To create Resource-Only TEST-RSRC.DLL library from text resource file TEST-RSRC.RC (compiled to intermediate binary TEST-RSRC.RES) it is possible to use MS tools (as documented in above link): RC.EXE TEST-RSRC.RC LINK.EXE /DLL /NOENTRY TEST-RSRC.RES Entrypoint of such library is set to zero. I'm trying to achieve same thing via binutils, but even with stripped debug symbols and zero entry point, LD somehow always puts .idata and .text sections with empty import table and something in code .text sections. Test case: $ cat test-rsrc.rc 1 VERSIONINFO BEGIN END $ i686-w64-mingw32-windres --input-format=rc --output-format=coff --input=test-rsrc.rc --output=test-rsrc.o $ i686-w64-mingw32-ld -dll --subsystem windows -e 0 -s test-rsrc.o -o test-rsrc.dll $ i686-w64-mingw32-objdump -h test-rsrc.dll test-rsrc.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0010 10001000 10001000 0400 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .idata0014 10002000 10002000 0600 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .rsrc 00b8 10003000 10003000 0800 2**2 CONTENTS, ALLOC, LOAD, DATA Is there some other flag for LD to achieve generation of resource-only DLL library? Or how to avoid putting (empty) .text and .idata sections into such DLL library? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #2 from Pali Rohár --- If adding empty import table and something in code .text sections is feature of the linker, it is somewhere documented? What it is doing and what is putting there (as those sections are not in any user supplied input file)? And I'm interesting why it is doing, it is some requirement for some SW? Just I'm currious here. And about objcopy --remove-section workaround, this is problematic because for automatization, it is needed to know what sections has to be removed - meaning ability to ask LD what additional section it added there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #4 from Pali Rohár --- (In reply to Nick Clifton from comment #3) > (In reply to Pali Rohár from comment #2) > > If adding empty import table and something in code .text sections is feature > > of the linker, it is somewhere documented? > > No. :-( > > > What it is doing and what is > > putting there (as those sections are not in any user supplied input file)? > > The (builtin, default) linker script is the cause. Ok! > > And I'm interesting why it is doing, it is some requirement for some SW? > > Just I'm currious here. > > The PE linker script automatically puts some constant values into the .text > section as markers between the normal code and the constructors and > destructors. If you run "ld --verbose" you will see this in the details for > the .text section: > > ... >LONG (-1); LONG (-1); >KEEP (*(.ctors)); >KEEP (*(.ctor)); >KEEP (*(SORT_BY_NAME(.ctors.*))); >LONG (0); LONG (0); >/* See comment about __CTOR_LIST__ above. The same reasoning > applies here too. */ >___DTOR_LIST__ = .; >__DTOR_LIST__ = .; >LONG (-1); LONG (-1); >KEEP (*(.dtors)); >KEEP (*(.dtor)); >KEEP (*(SORT_BY_NAME(.dtors.*))); >LONG (0); LONG (0); > ... > > These markers are used by the execution startup code to help find the two > tables. I see... But in this case there is nothing in .text section, just those markers. Does not linker script language support conditions to put markers only when at least one of those input sections is non-empty? So when input for that section is completely empty then also output section would be empty. > > > And about objcopy --remove-section workaround, this is problematic because > > for automatization, it is needed to know what sections has to be removed - > > meaning ability to ask LD what additional section it added there. > > In which case, just use --only-section instead. ie: > > $ objcopy --only-section=.rsrc test-rsrc.dll test-rsrc.3.dll > $ objdump -h test-rsrc.3.dll > test-rsrc.3.dll: file format pei-i386 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .rsrc 00b8 10003000 10003000 0200 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA This looks better. objcopy needs to be called also with -S to drop symbols which that LD script added. But still this --only-section does not remove .idata completelly. There is still reference to (now removed) import table and objdump prints warning about it. Visible also in readpe. $ readpe test-rsrc.3.dll | grep -A 6 'Data directories' export directory not found Data directories Directory IMAGE_DIRECTORY_ENTRY_IMPORT:0x2000 (20 bytes) Directory IMAGE_DIRECTORY_ENTRY_RESOURCE: 0x3000 (184 bytes) Imported functions Sections $ i686-w64-mingw32-objdump -p test-rsrc.3.dll | grep -A 19 'The Data Directory' The Data Directory Entry 0 Export Directory [.edata (or where ever we found it)] Entry 1 2000 0014 Import Directory [parts of .idata] Entry 2 3000 00b8 Resource Directory [.rsrc] Entry 3 Exception Directory [.pdata] Entry 4 Security Directory Entry 5 Base Relocation Directory [.reloc] Entry 6 Debug Directory Entry 7 Description Directory Entry 8 Special Directory Entry 9 Thread Storage Directory [.tls] Entry a Load Configuration Directory Entry b Bound Import Directory Entry c Import Address Table Directory Entry d Delay Import Directory Entry e CLR Runtime Header Entry f Reserved There is an import table, but the section containing it could not be found -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30376] New: windres cannot parse rc files which it itself generated
https://sourceware.org/bugzilla/show_bug.cgi?id=30376 Bug ID: 30376 Summary: windres cannot parse rc files which it itself generated Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- I took shell32.dll library from Windows XP. I have passed it to windres to generate RC file from it and then I passed this RC file back to windres to generate COFF object file from it. First phase DLL to RC is OK but in second phase windres throwed syntax error for the RC file which it itself generated. $ i686-w64-mingw32-windres --input-format=coff --output-format=rc -i shell32.dll -o shell32.rc $ i686-w64-mingw32-windres --input-format=rc --output-format=coff -i shell32.rc -o shell32.o i686-w64-mingw32-windres: shell32.rc:6473: syntax error i686-w64-mingw32-windres: preprocessing failed. Around line 6473 of generated file shell32.rc is: 6468 /* Type: "REGINST" 6469 6470Name: "REGINST". */ 6471 6472 "REGINST" "REGINST" 6473 BEGIN 6474 "[Version]\r\n" 6475 "Signature=""$CHICAGO$""\r\n" 6476 "[RegDll]\r\n" (note that in above output is one additional space after the line number added by me) It looks like a bug that windres cannot process in text RC files names with strings. But can process it from binary COFF files and even can generate text RC files with them. wrestool shows about this DLL library following information: $ wrestool -l shell32.dll --type='AVI' --name=150 --language=1033 [offset=0x3a9380 size=20796] --type='AVI' --name=151 --language=1033 [offset=0x3ae4c0 size=6144] --type='AVI' --name=152 --language=1033 [offset=0x3afcc0 size=6144] --type='AVI' --name=160 --language=1033 [offset=0x3b82c0 size=22016] --type='AVI' --name=161 --language=1033 [offset=0x3b14c0 size=14848] --type='AVI' --name=162 --language=1033 [offset=0x3b4ec0 size=13312] --type='AVI' --name=163 --language=1033 [offset=0x3bd8c0 size=13312] --type='AVI' --name=164 --language=1033 [offset=0x3c0cc0 size=13824] --type='AVI' --name=165 --language=1033 [offset=0x3c42c0 size=29184] --type='AVI' --name=166 --language=1033 [offset=0x3cb4c0 size=9728] --type='AVI' --name=167 --language=1033 [offset=0x3cdac0 size=19248] --type='AVI' --name=168 --language=1033 [offset=0x3d25f0 size=11802] --type='AVI' --name=169 --language=1033 [offset=0x3d5410 size=12722] --type='AVI' --name=170 --language=1033 [offset=0x3d85c8 size=10886] --type='REGINST' --name='REGINST' --language=1033 [offset=0x236c98 size=10] --type='TYPELIB' --name=1 --language=1033 [offset=0x7c4f10 size=33940] --type='UIFILE' --name=3 --language=1033 [offset=0x7ae208 size=1785] --type='UIFILE' --name=4 --language=1033 [offset=0x7ae908 size=2356] --type=1 --name=1 --language=1033 [type=cursor offset=0x3db050 size=308] --type=1 --name=2 --language=1033 [type=cursor offset=0x3db1a0 size=308] --type=1 --name=3 --language=1033 [type=cursor offset=0x3db2f0 size=308] --type=1 --name=4 --language=1033 [type=cursor offset=0x3db440 size=308] --type=1 --name=5 --language=1033 [type=cursor offset=0x3db590 size=308] ... When I replaced string name "REGINST" by integer name in (generated) text file shell32.rc and tried to compile shell32.rc I got another error message: $ i686-w64-mingw32-windres --input-format=rc --output-format=coff -i shell32.rc -o shell32.o i686-w64-mingw32-windres: shell32.rc:189276: syntax error Content around line 189276 is: 189268 /* Name: 14352. */ 189269 189270 14352 DIALOGEX 20, 20, 275, 198 189271 STYLE 0x80c800cc 189272 CAPTION "About %s" 189273 FONT 8, "MS Shell Dlg" 189274 BEGIN 189275 CONTROL 12297, 130, 0x5043, 21, 55, 21, 20 189276 CONTROL L"Microsoft \256 %s", 13568, 130, 0x508c, 70, 55, 165, 10 189277 CONTROL "", 13579, 130, 0x508c, 70, 65, 200, 10 189278 CONTROL L"Copyright \251 %s Microsoft Corporation", 13578, 130, 0x5080, 70, 75, 175, 10 189279 CONTROL "", 13581, 130, 0x5080, 70, 85, 145, 20 189280 CONTROL "This product is licensed under the terms of the End-User License Agreement to:", 13586, "SysLink", 0x5000, 70, 105, 145, 20 189281 CONTROL "user name", 13575, 130, 0x5080, 80, 125, 145, 10 189282 CONTROL "org name", 13576, 130, 0x5080, 80, 135, 145, 10 189283 CONTROL "", 13095, 130, 0x5010, 70, 147, 200, 1 189284 CONTROL "Physical memory available to Windows:", 13570, 130, 0x5080, 70
[Bug ld/30343] LTO ignores linker reference to _pei386_runtime_relocator
https://sourceware.org/bugzilla/show_bug.cgi?id=30343 --- Comment #3 from Pali Rohár --- I have looked at the LD source code but I'm really not sure if I understood it correclty. But for me it looks like that when LD generates runtime pseudo reloc then it tries to reference _pei386_runtime_relocator symbol. All runtime pseudo relocs are handled during runtime by the code statically linked into PE binary called from the startup PE code. And this handling is implemened in mingw function named _pei386_runtime_relocator(). So I guess that this referencing in linker is trying to ensure that in final generated binary is code responsible for handling of runtime pseudo relocs created by LD linker itself. And if this my assumption is correct then this can be reason why compiling with LTO throws that error because LTO compiler can inline that function into startup code and explicit _pei386_runtime_relocator symbol is not used at all. But I'm really not sure this is just my guessing. Cannot be issue in ld/pe-dll.c function pe_create_runtime_relocator_reference() in the way how this symbol _pei386_runtime_relocator is referenced there? Should not it be added to "resolution info" (not sure what it is) like was described in the gcc bug? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30381] New: Support for specifying new Windows PE option via manifests
https://sourceware.org/bugzilla/show_bug.cgi?id=30381 Bug ID: 30381 Summary: Support for specifying new Windows PE option via manifests Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- Target: mingw New features of Windows PE EXE/DLL binaries are being specified in embedded manifest. GNU LD currently does not support specifying these new options. It would be great to support modern features of Windows EXE/DLL binaries also in GNU LD linker. Documentation about Windows PE manifests is online at: https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30382] New: Add LD option for using UTF-8 code page in generated Windows PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30382 Bug ID: 30382 Summary: Add LD option for using UTF-8 code page in generated Windows PE binaries Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- Windows PE binaries generated by LD use by default legacy code page (e.g. CP1252) when working with any char* WinAPI function, including argv[] arguments in main. Legacy code pages do not support whole range of UNICODE characters and therefore passing non-ASCII filename via argv[] to main() loose processing of command line arguments. UTF-8 is now widely used, so LD should support generating Windows PE binaries in a way that are marked as UTF-8 compatible. Windows OS then will use UTF-8 as code page for all char* WinAPI function and will pass argv[] to main() in UTF-8 too. Switching code page to specific one for Windows PE binary is done by adding activeCodePage element into manifest. So please add some LD switch --active-code-page= for specifying code page which will be put into the final generated Windows PE binary. It should be considered for future that LD sets this --active-code-page= automatically to UTF-8 by default for all Windows PE binaries as usage of legacy code pages in application runtime is nowadays in UTF-8 ere just legacy. Please note that LD currently does not support manifests at all: https://sourceware.org/bugzilla/show_bug.cgi?id=30381 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359
--- Comment #6 from Pali Rohár ---
(In reply to Nick Clifton from comment #5)
> (In reply to Pali Rohár from comment #4)
>
> > > These markers are used by the execution startup code to help find the two
> > > tables.
> >
> > I see... But in this case there is nothing in .text section, just those
> > markers. Does not linker script language support conditions to put markers
> > only when at least one of those input sections is non-empty?
>
> Sadly, no.
I was thinking that it could be possible to define some linker variables before
and after those symbols to the current position and then do difference between
values of these variables. For example:
_BEGIN_OF_DATA_ = .
KEEP(...)
KEEP(...)
_END_OF_DATA_ = .
_LENGTH_OF_DATA_ = _END_OF_DATA_ - _BEGIN_OF_DATA_
And then somehow put
LONG (-1); LONG (-1);
only if _LENGTH_OF_DATA_ is non-zero.
This is also not possible by linker script language? Because it looks like very
common thing...
> But of course it is possible to create a copy of the linker script that does
> not contain these directives and then use that when creating the dll. I
> think that this could also solve the other problem...
>
> > But still this --only-section does not remove .idata completelly. There is
> > still reference to (now removed) import table and objdump prints warning
> > about it. Visible also in readpe.
>
> Except - when I tried to create a simple test to verify this I ran into a
> problem. The dll linked OK with my test linker script:
>
> $ i686-w64-mingw32-ld -dll --subsystem windows -e 0 -s test-rsrc.o -o
> test-rsrc.dll -T test-rsrc.ld
>
> and it only has the .rsrc section:
>
> $ i686-w64-mingw32-objdump -h test-rsrc.2.dll
>
> test-rsrc.dll: file format pei-i386
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .rsrc 00b8 0200 2**2
>
> but, when I checked it with objdump, it complains about the .rsrc section
> being corrupt:
>
> $ i686-w64-mingw32-objdump -p test-rsrc.2.dll
>
> test-rsrc.2.dll: file format pei-i386
> [...]
> The .rsrc Resource Directory section:
> 000 Type Table: Char: 0, Time: , Ver: 0/0, Num Names: 0, IDs: 1
> 010 Entry: ID: 0x10, Value: 0x8018
> 018Name Table: Char: 0, Time: , Ver: 0/0, Num Names: 0, IDs: 1
> 028 Entry: ID: 0x01, Value: 0x8030
> 030 Language Table: Char: 0, Time: , Ver: 0/0, Num Names: 0,
> IDs: 1
> 040 Entry: ID: 0x000409, Value: 0x48
> 048Leaf: Addr: 0x58, Size: 0x5c, Codepage: 0
> Corrupt .rsrc section detected!
That is really strange.
> I think that this might be due to missing padding at the end of the section,
> but I am not sure. Given that you are a windows expert, perhaps you can
> find out more ?
I have looked at the output and file seems to be correct. It does not missing
any padding. I have replaced simple resource file by one with large icons and I
still can see this error in objdump. I have tried to use this icon-only-dll on
Windows and it loaded icons from this file without any issue.
So I have feeling that generated DLL file is valid and this is bug in the
binutils PE parser.
What is interesting on this DLL file is that it has .rsrc section located to
VMA address 0x0:
Entry 2 00b8 Resource Directory [.rsrc]
I'm not sure if it is fully OK but if Windows do not see any problem with it
then it is acceptable.
And resource entry points to VMA address 0x58 which is in the range
0x0-0xb8 of .rsrc:
048Leaf: Addr: 0x58, Size: 0x5c, Codepage: 0
So this is also correctly generated.
I played a bit with binutils code and found out that zero VMA in peicode.h is
handled specially - as ignored. I'm feeling that this rather should have been
check if directory entry is available/valid. So should not it rather check
non-zero size?
I have done simple change
--- peicode.h 2023-04-25 21:01:05.005927648 +0200
+++ peicode.h 2023-04-25 21:01:30.558118254 +0200
@@ -223,15 +223,15 @@ coff_swap_scnhdr_in (bfd * abfd, void *
+ (H_GET_16 (abfd, scnhdr_ext->s_nreloc) << 16));
scnhdr_int->s_nreloc = 0;
#else
scnhdr_int->s_nreloc = H_GET_16 (abfd, scnhdr_ext->s_nreloc);
scnhdr_int->s_nlnno = H_GET_16 (abfd, scnhdr_ext->s_nlnno);
#endif
- if (scnhdr_int->s_vaddr != 0)
+ if (scnhdr_int->s_size != 0)
{
scnhdr_int->s_vaddr += pe_data (abfd)->pe_opthdr.ImageBase;
/* Do not cut upper 32-bits for 64-bit vma. */
#ifndef COFF_WITH_pex64
scnhdr_int->s_vaddr &= 0x;
#endif
}
And with it, objdump that generated DLL accepted.
But I really do not know if the issue is that LD put .rsrc to VMA address 0x0
or that OBJDUMP does not correctly re-calculate address of sections with VMA
0x0.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30390] New: Allow to specify custom stub for PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30390 Bug ID: 30390 Summary: Allow to specify custom stub for PE binaries Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- MS linker has option /STUB for specifying custom stub binary which is included into final PE binary. GNU LD has hardcoded stub binary and does not allow user to specify custom stub binary like MS linker. Please add some new LD --stub option which changes the default GNU LD stub with one supplied by user. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #7 from Pali Rohár --- Or maybe instead of "if (scnhdr_int->s_vaddr != 0)" it should be "#ifdef COFF_IMAGE_WITH_PE"? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #9 from Pali Rohár --- That check s_size != 0 does not really look good. I have quickly scanned wine and reactos source codes and seems that they require non-zero VMA addresses for resources. Maybe another check could be based on existance of IMAGE_SCN_MEM_DISCARDABLE flag? Well, this zero VMA for resource section is edge case. Why is LD generating it? I think that this is what should be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30300] LTO drops entry point symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=30300 --- Comment #3 from Pali Rohár --- Do you need some more testing? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #10 from Pali Rohár --- Checking IMAGE_SCN_MEM_DISCARDABLE is not a good idea too as this section is still loaded from .sys drivers and discarded after driver is initialized. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30343] LTO ignores linker reference to _pei386_runtime_relocator
https://sourceware.org/bugzilla/show_bug.cgi?id=30343 --- Comment #5 from Pali Rohár --- Hello! I have test proposed fix and it works fine. Both LTO and non-LTO versions are correctly generated. Also everything is working fine when there is no psuedo reloc and _pei386_runtime_relocator() is not defined/compiled at all. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #12 from Pali Rohár --- This new linker script works fine. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #4 from Pali Rohár --- So it looks like that IMAGE_SCN_MEM_READ characteristic is always added, IMAGE_SCN_MEM_WRITE characteristic is added only when readonly flag is not specified. And other flags add following characteristics: alloc --> IMAGE_SCN_CNT_UNINITIALIZED_DATA noload --> IMAGE_SCN_MEM_DISCARDABLE debug --> IMAGE_SCN_CNT_INITIALIZED_DATA + IMAGE_SCN_MEM_DISCARDABLE code --> IMAGE_SCN_CNT_CODE + IMAGE_SCN_MEM_EXECUTE data --> IMAGE_SCN_CNT_INITIALIZED_DATA exclude --> IMAGE_SCN_MEM_DISCARDABLE share --> IMAGE_SCN_MEM_SHARED What is difference between noload and exclude? Seems that both flags do same thing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30376] windres cannot parse rc files which it itself generated
https://sourceware.org/bugzilla/show_bug.cgi?id=30376 --- Comment #2 from Pali Rohár --- I'm not sure if I can upload that generated file here due to possible legal problems. But if you agree, you can download some other shell32.dll from the internet. For example I found different version on https://www.dll-files.com/shell32.dll.html (6.0.2900.6072 / 98f2e089891cae87147f74948f694565) for which GNU windres generates shell32.rc file with same syntax errors. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30390] Allow to specify custom stub for PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30390 --- Comment #2 from Pali Rohár --- Stub is executable code, I think it can be any valid binary in MZ format. Restrictions about alignement or size would come from the MZ format itself. About objcopy, I do not know about any way how to replace stub binary from existing PE binary. I think that replacement is harder operation because absolute offsets in PE structures needs to be adjusted when stub changes it size. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #14 from Pali Rohár --- Well, if this is the way how it should be used then "fixed" linker script should be distributed with linker. Or at least described in the LD documentation. Because it is really hard to find some information or figure out how to use it. Bugzilla is not really a good place for documentation. And what about other bugs discovered in this bug report? There is a problem in LD that it can generate section to zero VMA address. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30376] windres cannot parse rc files which it itself generated
https://sourceware.org/bugzilla/show_bug.cgi?id=30376
--- Comment #5 from Pali Rohár ---
Finally I found documentation about named resources which caused this issue:
https://learn.microsoft.com/en-us/windows/win32/menurc/user-defined-resource
And here there is no information that name or type should be quoted. Also in
example is both name and type unquoted.
So I did an experiment with simple RC file:
$ cat RESOURCE.RC
resource_name resource_type { "resource_string_data" }
I compiled it with MS resource compiler RC.EXE to RESOURCE.RES file:
$ RC.EXE RESOURCE.RC
It accepted it and did not print any warning / error.
Then I created resource-only DLL with the linker script which you provided:
$ i686-w64-mingw32-windres RESOURCE.RES RESOURCE.OBJ
$ i686-w64-mingw32-ld -dll --subsystem windows -e 0 -s RESOURCE.OBJ -o
RESOURCE.DLL -T resource-only.ld
And then printed resources via wrestool:
$ wrestool -l RESOURCE.DLL
--type='RESOURCE_TYPE' --name='RESOURCE_TYPE' --language=1033 [offset=0x1090
size=20]
(I'm not sure why it prints wrong name, but whatever).
Next I did another experiment with following resource file, when I quoted name
and type:
$ cat RESOURCE.RC
"resource_name" "resource_type" { "resource_string_data" }
And again compiled it with MS RC.EXE compiler and created resource-only DLL
with GNU tools. MS compiler accepted this input file without any warning or
error. And wrestool showed:
$ wrestool -l RESOURCE.DLL
--type='"RESOURCE_TYPE"' --name='"RESOURCE_TYPE"' --language=1033
[offset=0x1098 size=20]
Look at the type, it is quited. So it looks like that name in RC file should be
taken as-is, if it contains quotes then quotes are part of the name. And it
means that GNU windres does not generate correct RC file and also does not
parse RC file correctly.
I will try your windres patch later and let you know the results.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30376] windres cannot parse rc files which it itself generated
https://sourceware.org/bugzilla/show_bug.cgi?id=30376 --- Comment #6 from Pali Rohár --- Hello Nick! Now I tried your patch. Now it is better because windres can compile its own generated rc file. But there are still issues. I did more repeated conversions between binary and text file via these steps: $ i686-w64-mingw32-windres shell32.dll shell32.dll.rc $ i686-w64-mingw32-windres shell32.dll.rc shell32.dll.rc.res i686-w64-mingw32-windres: warning: 14: 1001: 1033: duplicate value i686-w64-mingw32-windres: warning: 14: 1002: 1033: duplicate value i686-w64-mingw32-windres: warning: 14: 1003: 1033: duplicate value i686-w64-mingw32-windres: warning: 14: 1004: 1033: duplicate value i686-w64-mingw32-windres: warning: 14: 1005: 1033: duplicate value $ i686-w64-mingw32-windres shell32.dll.rc.res shell32.dll.rc.res.rc $ i686-w64-mingw32-windres shell32.dll.rc.res.rc shell32.dll.rc.res.rc.res $ i686-w64-mingw32-windres shell32.dll.rc.res.rc.res shell32.dll.rc.res.rc.res.rc And I see more issues. First issue is that every one *.rc file is different individual resources have different content. So it means that either compiler or decompiler is doing something wrong if it changes content. Second issue is that second windres call drops RT_GROUP_CURSOR and RT_GROUP_ICON during compilation. It throws that duplicate value warning, but there are no duplicates. Seems that checking for duplicates is improper. See following output: $ grep '^1001 ' shell32.dll.rc shell32.dll.rc.res.rc shell32.dll.rc:1001 3 /* RT_ICON */ shell32.dll.rc:1001 12 /* RT_GROUP_CURSOR */ shell32.dll.rc:1001 14 /* RT_GROUP_ICON */ shell32.dll.rc.res.rc:1001 3 /* RT_ICON */ MOVEABLE PURE DISCARDABLE shell32.dll.rc.res.rc:1001 14 /* RT_GROUP_ICON */ MOVEABLE PURE DISCARDABLE It looks like that windres during duplication checks only for name, not for tuple (name, type). Third issue is that windres starts adding MOVEABLE PURE DISCARDABLE attributes even they were not in previous iteration of compilation / decompilation. I'm not sure if they should be there or not. But I was expecting that res --> rc --> res --> rc actions would convergate to one stable rc file. Fourth issue: Resource "2 1" (cursor) has completely different content in shell32.dll.rc and shell32.dll.rc.res.rc files. diff is: /* Name: 2. */ -2 1 /* RT_CURSOR */ +2 1 /* RT_CURSOR */ MOVEABLE PURE DISCARDABLE BEGIN 0x1, 0x3, /* Hotspot x: 1, y: 3. */ - 0x28L , 0x20L , 0x40L , 0x10001L , 0x0L , 0x100L , 0x0L , 0x0L , - 0x0L , 0x0L , 0x0L , 0xffL , 0x0L , 0x0L , 0x0L , 0x0L , - 0x0L , 0x0L , 0x0L , 0x0L , 0x0L , 0xcL , 0x1eL , 0x1fL , - 0x80ff0700L, 0xc0ff1f00L, 0xe0cf3700L, 0xc0ff6f00L, 0x80cfdf00L, 0xcfbf00L , 0xe77f00L , 0xe37f00L , - 0x33ff00L , 0x3ef01L , 0x86df03L , 0xfcbd07L , 0xf83b0fL , 0x70371eL , 0xe00e3cL , 0xc00d38L , - 0x300L , 0x0L , 0x0L , 0x0L , 0xL, 0xL, 0xL, 0xL, - 0xL, 0xL, 0xL, 0xL, 0xfff7L, 0xffe3L, 0xffc1L, 0xff00f8ffL, - 0x7f00e0ffL, 0x3f00c0ffL, 0x1f0080ffL, 0x1fffL, 0x3ffeL, 0x7ffeL, 0x7ffeL, 0x7fffL, - 0x7ffeL, 0x7ffcL, 0xfff8L, 0xff0100f0L, 0xff0300e0L, 0xff0780c0L, 0xff0fc081L, 0xff1fe083L, - 0xff3ff087L, 0xfcffL, 0xL, 0xL + 0xed005e70L, 0x55d5L, 0x1L , 0x0L , 0x40L , 0x0L , 0x0L , 0x0L , + 0xed005e90L, 0x55d5L, 0x1L , 0x0L , 0x10001L , 0x0L , 0x0L , 0x0L , + 0xed005eb0L, 0x55d5L, 0x1L , 0x0L , 0x0L , 0x0L , 0x0L , 0x0L , + 0xed005ed0L, 0x55d5L, 0x1L , 0x0L , 0x100L , 0x0L , 0x0L , 0x0L , + 0xed005ef0L, 0x55d5L, 0x1L , 0x0L , 0x0L , 0x0L , 0x0L , 0x0L , + 0xed005f10L, 0x55d5L, 0x1L , 0x0L , 0x0L , 0x0L , 0x0L , 0x0L , + 0xed005f30L, 0x55d5L, 0x1L , 0x0L , 0x0L , 0x0L , 0x0L , 0x0L , + 0xed005f50L, 0x55d5L, 0x1L , 0x0L , 0x0L , 0x0L , 0x0L , 0x0L , + 0xed005f70L, 0x55d5L, 0x1L , 0x0L , 0x0L , 0x0L , 0x0L , 0x0L , + 0xed005f90L, 0x55d5L, 0x1L , 0x0L END -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30376] windres cannot parse rc files which it itself generated
https://sourceware.org/bugzilla/show_bug.cgi?id=30376
--- Comment #7 from Pali Rohár ---
I did also another test. I took very simple resource file:
$ cat test-resource.rc
resource_name1 resource_type1 { "resource_string_data1" }
resource_name2 "resource_type2" { "resource_string_data2" }
"resource_name3" resource_type3 { "resource_string_data3" }
"resource_name4" "resource_type4" { "resource_string_data4" }
With MS RC.EXE compiler I can compile it, it does not throw any warning /
error:
$ RC.EXE /fo test-resource.ms.res test-resource.rc
If I try to compile it with GNU windres, it throws syntax error:
$ i686-w64-mingw32-windres test-resource.rc test-resource.gnu.res
i686-w64-mingw32-windres: test-resource.rc:4: syntax error
Binary resource test-resource.ms.res compiled by MS compiler I can put into
resource-only DLL via MS linker and then list its content via wrestool:
$ LINK.EXE /NOLOGO /DLL /NOENTRY /MACHINE:IX86 /OUT:test-resource.ms.dll
test-resource.ms.res
$ $ wrestool -l test-resource.ms.dll
--type='"RESOURCE_TYPE2"' --name='"RESOURCE_TYPE2"' --language=1033
[offset=0x1248 size=21]
--type='"RESOURCE_TYPE4"' --name='"RESOURCE_TYPE4"' --language=1033
[offset=0x1278 size=21]
--type='RESOURCE_TYPE1' --name='RESOURCE_TYPE1' --language=1033 [offset=0x1230
size=21]
--type='RESOURCE_TYPE3' --name='RESOURCE_TYPE3' --language=1033 [offset=0x1260
size=21]
And now if I decompile resource.ms.res via GNU windres I get following output:
$ i686-w64-mingw32-windres test-resource.ms.res
/* Type: """RESOURCE_TYPE2"""
Name: "RESOURCE_NAME2". */
LANGUAGE 9, 1
"RESOURCE_NAME2" """RESOURCE_TYPE2""" MOVEABLE PURE
BEGIN
0x6f736572L, 0x65637275L, 0x7274735fL, 0x5f676e69L, 0x61746164L,
"2"
END
/* Type: """RESOURCE_TYPE4"""
Name: """RESOURCE_NAME4""". */
"""RESOURCE_NAME4""" """RESOURCE_TYPE4""" MOVEABLE PURE
BEGIN
0x6f736572L, 0x65637275L, 0x7274735fL, 0x5f676e69L, 0x61746164L,
"4"
END
/* Type: "RESOURCE_TYPE1"
Name: "RESOURCE_NAME1". */
"RESOURCE_NAME1" "RESOURCE_TYPE1" MOVEABLE PURE
BEGIN
0x6f736572L, 0x65637275L, 0x7274735fL, 0x5f676e69L, 0x61746164L,
"1"
END
/* Type: "RESOURCE_TYPE3"
Name: """RESOURCE_NAME3""". */
"""RESOURCE_NAME3""" "RESOURCE_TYPE3" MOVEABLE PURE
BEGIN
0x6f736572L, 0x65637275L, 0x7274735fL, 0x5f676e69L, 0x61746164L,
"3"
END
It is clear that it is not what was on the input as resource name and types
have messed quote character. Content seems to be correct, it is just encoded in
less readable DWORDs form instead of ASCII string.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #17 from Pali Rohár --- Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #6 from Pali Rohár --- IMAGE_SCN_LNK_REMOVE is valid only for object files, not for executables. But yes, from above description exclude flag should be mapped to IMAGE_SCN_LNK_REMOVE characteristics. Also it would be great to synchronize support for these flags with flags supported by assembler: https://sourceware.org/binutils/docs/as/Section.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30390] Allow to specify custom stub for PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30390 --- Comment #4 from Pali Rohár --- Ok, I understand reasons. And I think that replacing 64-byte array by another with same size by some special linker flag has likely very small value, because this simple replacement can be done by e.g. dd tool. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145
--- Comment #8 from Pali Rohár ---
Thank you. I have looked at the change and from documented IMAGE_SCN_* flags at
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format and for dumping
in section_flag_xlat[] are missing: IMAGE_SCN_GPREL, IMAGE_SCN_MEM_16BIT and
IMAGE_SCN_ALIGN_*
And in older version of PE spec are defined also these section characteristics:
#define IMAGE_SCN_TYPE_DSECT 0x0001 // Reserved.
#define IMAGE_SCN_TYPE_NO_LOAD 0x0002 // Reserved.
#define IMAGE_SCN_TYPE_GROUPED 0x0004 // Section is grouped with other
sections by name.
#define IMAGE_SCN_TYPE_COPY 0x0010 // Reserved.
#define IMAGE_SCN_LNK_OVERLAY0x0400 // Section contains an overlay.
Just few weeks ago I sent a patch for readpe to recognizie all known PE machine
types: https://github.com/mentebinaria/readpe/issues/186 So maybe you can reuse
it for decode_machine_number() function.
And I have one other suggestion for string names in section_flag_xlat[].
Constants with prefix IMAGE_SCN_LNK_*, IMAGE_SCN_ALIGN_* and also some
IMAGE_SCN_TYPE_* are something like instructions for linker, so they should not
appear in the final PE executable binary, but only in COFF object files
(without PE header). Maybe it would make sense to print them IMAGE_SCN_LNK_*
with LNK_ prefix? E.g. as { IMAGE_SCN_LNK_OTHER, "LNK_OTHER" },
About IMAGE_DOS_SIGNATURE magic, I agree that printing it has no reason as it
is required to be in the DOS header. But what can be interesting is magic
number of Optional Header (after the File/COFF header). It can be either
IMAGE_NT_OPTIONAL_HDR32_MAGIC (0x10b aka PE32), IMAGE_NT_OPTIONAL_HDR64_MAGIC
(0x20b aka PE32+) or IMAGE_ROM_OPTIONAL_HDR_MAGIC (0x107 aka ROM, used in
COFF-only images).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #9 from Pali Rohár --- Ou, now I see that IMAGE_SCN_GPREL is alias for IMAGE_SCN_MEM_FARDATA and IMAGE_SCN_MEM_16BIT alias for IMAGE_SCN_MEM_PURGEABLE. And these twos are already in section_flag_xlat[]. And IMAGE_SCN_TYPE_DSECT is alias for IMAGE_SCN_TYPE_DUMMY (DummySECTion). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30496] New: Add support for PE IMAGE_SCN_MEM_16BIT section characteristic
https://sourceware.org/bugzilla/show_bug.cgi?id=30496 Bug ID: 30496 Summary: Add support for PE IMAGE_SCN_MEM_16BIT section characteristic Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- PE for machine type of IMAGE_FILE_MACHINE_I386 (0x014c) can contain IMAGE_SCN_MEM_16BIT (0x0002) in section characteristics. When IMAGE_SCN_MEM_16BIT is specified then section contain 16-bit x86 code. Microsoft DUMPBIN.EXE recognize this characteristic and show its name as "Purgeable or 16-Bit". And sections marked with this characteristic disassemble as 16-bit instead of default 32-bit. Note that PE IMAGE_SCN_MEM_PURGEABLE characteristic has same value as IMAGE_SCN_MEM_16BIT = 0x0002, but my experiments reveal that for MS tools IMAGE_SCN_MEM_16BIT seems to be I386 specific and IMAGE_SCN_MEM_PURGEABLE seems to be M68K specific. Here is very simple object file test.obj with two functions _test32 and _test16 which are in different sections with and without IMAGE_SCN_MEM_16BIT characteristics. $ xxd test.obj : 4c01 0200 a94f 7364 6a00 0a00 LOsdj... 0010: 2e74 6578 7400 .text... 0020: 0300 6400 d... 0030: 2010 1060 2e74 6578 ..`.tex 0040: 7400 0300 0300 t... 0050: 6700 g... 0060: 2010 1260 33c0 c333 c0c3 2e66 696c 6500 ..`3..3...file. 0070: feff 6701 7465 7374 ..g.test 0080: 2e63 5f74 .c_t 0090: 6573 7433 3200 2000 0200 est32... ... 00a0: 2e74 6578 7400 0100 .text... 00b0: 0301 0300 00c0: 0100 5f74 6573 7433 3200 _test32. 00d0: 0100 2000 0200 5f74 6573 7431 3600 .. ..._test16... 00e0: 2000 0200 2e74 6578 7400 text... 00f0: 0200 0301 0300 0100: 0100 5f74 6573 _tes 0110: 7431 3600 0200 2000 0200 0400 t16... . 0120: .. Microsoft DUMPBIN.EXE correcly recognize IMAGE_SCN_MEM_16BIT in _test16 and disassemble "0x33 0xC0" as "xor ax,ax": $ DUMPBIN.EXE /DISASM /HEADERS test.obj ... SECTION HEADER #1 .text name 0 physical address 0 virtual address 3 size of raw data 64 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 60101020 flags Code Communal; sym= _test32 1 byte align Execute Read _test32: : 33 C0 xor eax,eax 0002: C3 ret DUMPBIN : warning LNK4078: multiple ".text" sections found with different attributes (60121020) SECTION HEADER #2 .text name 3 physical address 0 virtual address 3 size of raw data 67 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 60121020 flags Code Communal; sym= _test16 Purgeable or 16-Bit 1 byte align Execute Read _test16: 0002:: 33 C0 xor ax,ax 0002:0002: C3 ret Summary 3 .text 3 .text But GNU objdump does not recognize it and disassemble "0x33 0xC0" in 32-bit mode as "xor %eax,%eax": $ i686-w64-mingw32-objdump -d test.mod.obj test.obj: file format pe-i386 Disassembly of section .text: <_test32>: 0: 33 c0 xor%eax,%eax 2: c3 ret Disassembly of section .text: <_test16>: 0: 33 c0 xor%eax,%eax 2: c3 ret Also assembling simple code with .code16 directive with GNU AS does not set IMAGE_SCN_MEM_16BIT section characteristic. Test case: $ cat test-16bit.S .section .text32, "rx0" _test32: xor %eax, %eax ret .section .text16, "rx0" .code16 _test16: xor %ax, %ax ret $ i686-w64-mingw32-as -o test-16bit.o test-16bit.S $ i686-w64-mingw32-objdump -d test-16bit.o test-16bit.o: file format pe-i386 Disassembly of section .text32: <_test32>: 0: 31 c0 xor%eax,%eax 2: c3 ret
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #10 from Pali Rohár --- Ah, flag 0x0002 has not only two differet names IMAGE_SCN_MEM_16BIT and IMAGE_SCN_MEM_PURGEABLE, but also two different meanings. For IMAGE_FILE_MACHINE_I386 it is means that section is 16-bit, for IMAGE_FILE_MACHINE_M68K it is set when section is executable (not sure why) and for other IMAGE_FILE_MACHINE_* it seems to do nothing. It looks like that MS used flag 0x0002 for platform specific things. I guess that other "aliased" flags would have also different meanings for different platforms... I created bug #30496 and described here how IMAGE_SCN_MEM_16BIT behaves. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30496] Add support for PE IMAGE_SCN_MEM_16BIT section characteristic
https://sourceware.org/bugzilla/show_bug.cgi?id=30496 --- Comment #1 from Pali Rohár --- I have tested that DUMPBIN.EXE recognize IMAGE_SCN_MEM_16BIT also for other non-x86 platforms: IMAGE_FILE_MACHINE_MIPS16 (0x266), IMAGE_FILE_MACHINE_MIPSFPU16 (0x466) (where section is 16-bit) and in IMAGE_FILE_MACHINE_THUMB (0x1c2) where section is in Thumb/Thumb2 ISA (also when in section are 4-byte thumb instructions) as opposite of the ARM ISA. So it looks like that IMAGE_SCN_MEM_16BIT can be used for any architecture where something like 16-bit / 2-byte flag has some meaning. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30496] Add support for PE IMAGE_SCN_MEM_16BIT section characteristic
https://sourceware.org/bugzilla/show_bug.cgi?id=30496 --- Comment #2 from Pali Rohár --- I have tested that MS LINK.EXE put IMAGE_SCN_MEM_16BIT also into the final EXE file for section which was marked with this flag in object file. And also DUMPBIN.EXE recognize IMAGE_SCN_MEM_16BIT in EXE executables (not just in object files). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30376] windres cannot parse rc files which it itself generated
https://sourceware.org/bugzilla/show_bug.cgi?id=30376 --- Comment #8 from Pali Rohár --- Hello Nick, have you looked at my above comments? Do you need more tests here? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30390] Allow to specify custom stub for PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30390 --- Comment #5 from Pali Rohár --- Anyway, I see that for GO32 MZ binaries is bfd using GO32STUB env variable to specify other custom stub (bfd/coff-stgo32.c). So maybe this can be unified? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30922] New: gcc -pie generates unwanted PE export table
https://sourceware.org/bugzilla/show_bug.cgi?id=30922
Bug ID: 30922
Summary: gcc -pie generates unwanted PE export table
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
Target: x86_64-w64-mingw32
Originally reported on: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108851
When gcc is invoked with -pie option then for PE executables it automatically
generates export table, even when executable does not export anything.
Test case:
$ cat test-pie.c
int func(void) {
return 42;
}
int main() {
return func();
}
$ x86_64-w64-mingw32-gcc -pie test-pie.c -o test-pie.exe
$ x86_64-w64-mingw32-objdump -p test-pie.exe | grep -A 20 'There is an export
table'
There is an export table in .edata at 0x140008000
The Export Tables (interpreted .edata section contents)
Export Flags0
Time/Date stamp 63f2a29f
Major/Minor 0/0
Name8028 test-pie.exe
Ordinal Base1
Number in:
Export Address Table
[Name Pointer/Ordinal] Table
Table Addresses
Export Address Table8028
Name Pointer Table 8028
Ordinal Table 8028
Export Address Table -- Ordinal Base 1
[Ordinal/Name Pointer] Table
Without gcc's -pie option, executable does not have export table.
Note that similar issue was reported also to LD
https://sourceware.org/bugzilla/show_bug.cgi?id=30004 and proposed LD patch
does not change behavior in this issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #12 from Pali Rohár --- https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#special-sections Some section names are reserved and .text is really there with IMAGE_SCN_CNT_CODE | IMAGE_SCN_MEM_EXECUTE | IMAGE_SCN_MEM_READ characteristics. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30376] windres cannot parse rc files which it itself generated
https://sourceware.org/bugzilla/show_bug.cgi?id=30376 --- Comment #11 from Pali Rohár --- (In reply to Nick Clifton from comment #10) > I think the point that you are trying to make however is that the MS > resource compiler actually includes the double quote characters as part of > the resource names, correct ? Yes, above test proves that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30376] windres cannot parse rc files which it itself generated
https://sourceware.org/bugzilla/show_bug.cgi?id=30376 --- Comment #13 from Pali Rohár --- Ok, if it is not possible to fix this particular case then it would be useful to document this incompatibility with MS RC format. I can understand that rewriting the whole parser is not something which is going to happen just because of this issue. Also it could be useful if instead of the generic message "syntax error" is printed some more describing message like "MS-style double quotes are not supported" but I can imagine that the whole error message processing is part of the parser and hence even this is not possible to fix. So documentation change is the best fix there. And what about other issues described in comment #6? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30376] windres cannot parse rc files which it itself generated
https://sourceware.org/bugzilla/show_bug.cgi?id=30376 --- Comment #14 from Pali Rohár --- Hello, have you looked at the problem described in comment #6 that res --> rc --> res --> rc actions are changing attributes? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30922] gcc -pie generates unwanted PE export table
https://sourceware.org/bugzilla/show_bug.cgi?id=30922 --- Comment #1 from Pali Rohár --- Just to note that Position Independet Executable and Export Table are two totally different things. You can have (and it is pretty standard) to have fixed-address executable without relocation table (so it always must be loaded at specific virtual address) and this executable export some symbols/functions to other later loaded DLL libraries. For example if application executable support plugins and these plugins need to call application functions. It is plugin DLL which must have relocation table for loading it at any address, but for calling application executable function, there is absolutely no need to have relocation table for application executable itself. So it looks like that -pie option is duing two different and unrelated things: generating relocation table and generating export table. And this should be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30144] LD --entry does not accept function name
https://sourceware.org/bugzilla/show_bug.cgi?id=30144 --- Comment #3 from Pali Rohár --- > Looking into this, it is actually quite hard to predict the mangling of the > entry symbol name. Nick, cannot be 32-bit x86 PE ld easily extended in this way? When --entry=XYZ is specified at command line then ld first try to find symbol "XYZ" and if it does not exist then it tries to find symbol "_XYZ@8". Mangling is target specific, so it should be easily predictable. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #13 from Pali Rohár --- Nick, do you plan to update your change? I think it is a good starting point. I would propose to do not allow these options to be available on non-PE targets (e.g. ELF) as it can be confusing. Just to note that now in readpe project you can find all IMAGE_SCN_* flags with simple description of the meaning, also those which are missing in MS pe-format document. https://github.com/mentebinaria/readpe/blob/master/lib/libpe/include/libpe/sections.h -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30147] Allow to specify PE export name
https://sourceware.org/bugzilla/show_bug.cgi?id=30147 --- Comment #4 from Pali Rohár --- Also I must admit that it is annoying if some flags has to be passed to LD as command line arguments and some other flags via (new temporary) file which is specified as command line argument. It is highly unexpected usage/behavior. I see that -soname for ELF targets has quite different meaning than PE export name, even that it is used for similar purposes. Nick, what about these changes? * Throws warning or maybe better error when -soname= is specified for non-ELF target (targets which do not support soname). * Document that -soname= is ELF specific. Document how to set PE export name, what is default value and how ELF soname and PE export name differs. * Add a new command line option for setting PE export name (+ document it) for both DLL libraries and EXE executables. I do not know what can be the best name but reusing -soname is not a good idea (as it does quite different thing). Maybe -pe-export-name? Or -exportname? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31543] New: windres announces non-PE targets as supported
https://sourceware.org/bugzilla/show_bug.cgi?id=31543 Bug ID: 31543 Summary: windres announces non-PE targets as supported Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- Windres in documentation has described that it supports only COFF and RES binary formats. Which is correct as the Windows resources are stored and used only in Windows COFF formats. But windres --help announces that it supports also lot of other non-PE targets, including ELF target. Trying to use use ELF target cause fatal error: $ x86_64-w64-mingw32-windres --target="elf64-x86-64" -i test.rc -o test.o x86_64-w64-mingw32-windres: can't get BFD_RELOC_RVA relocation type: cause of error unknown I think that this is a bug, windres should not accounce in --help and also should not accept any non-COFF target. Also it should not announce or accept PE/COFF target with MZ/PE executable header (EXE/DLL) as it cannot generate resource-only DLL file. Windres can generate only COFF object file which is without MZ/PE header. This issue was described in gcc bugzilla comment: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866#c7 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31544] New: Incorrect default subsystem version for POSIX PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=31544 Bug ID: 31544 Summary: Incorrect default subsystem version for POSIX PE binaries Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- GNU LD currently by default for POSIX PE binaries generated by --subsystem=posix option sets subsystem version to 4.0. MS LINK.EXE (via /SUBSYSTEM:POSIX) sets POSIX subsystem version to 19.90. Version 4.0 refers to Windows version, 19.90 refers to POSIX 1990. GNU LD should follow what MS LINK.EXE sets as POSIX PE binaries are not for windows 4.0 subsystem. Subsystem version via GNU LD can be explicitly set via --subsystem=posix:19.90 and this should be the default version when just --subsystem=posix is specified. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31659] New: Fix Windows DEF file documentation
https://sourceware.org/bugzilla/show_bug.cgi?id=31659 Bug ID: 31659 Summary: Fix Windows DEF file documentation Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- binutils documentation for Windows DEF file is currently at these locations: * https://sourceware.org/binutils/docs/binutils/def-file-format.html * https://sourceware.org/binutils/docs/ld/WIN32.html First one documents EXPORTS keyword as: EXPORTS ( ( ( name1 [ = name2 ] ) | ( name1 = module-name . external-name ) ) [ == its_name ] [ integer ] [ NONAME ] [ CONSTANT ] [ DATA ] [ PRIVATE ] ) * And second one as: EXPORTS ( ( ( [ = ] ) | ( = . )) [ @ ] [NONAME] [DATA] [CONSTANT] [PRIVATE] [== ] ) * As can be seen these specifications differs. First one does not accept trailing "== name3" for symbol aliasing and second one requires @ before integer for specifying ordinal of the symbol. Also the first one contains sentense "see PR binutils/13710 for more details" but there is no hyperlink to which it referes. Also there is no explanation where is that PR (pull request?). Please update binutils documentations to specify format of DEF file correctly. So that documentation would match the format used & supported by binutils. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31659] Fix Windows DEF file documentation
https://sourceware.org/bugzilla/show_bug.cgi?id=31659 --- Comment #1 from Pali Rohár --- Interesting... bugzilla added hyperlink to PR keyword, I thought it is reference to some pull request. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] New: dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728
Bug ID: 31728
Summary: dlltool generates incorrect hints in import libraries
Product: binutils
Version: 2.43 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: pali at kernel dot org
Target Milestone: ---
When dlltool is requested to generate import library from the def file, it
generates incorrect hints of the symbols.
I scanned the git repository I and found that breakage happened by commit
35fd2ddeb1d90f1750401cfb6d01fe055656b88d (Generate correct hint value for
IDATA6). Before that commit it was correct.
After reverting this commit on top of the master branch, dlltool started
generated correct hints again for symbols into import library.
Test case for reproducing this problem:
First create very simple DLL library with 3 exported functions:
cat library.c
void func2(void) {}
void func1(void) {}
void func0(void) {}
int __attribute__((stdcall)) _DllMainCRTStartup(void *handle, unsigned int
reason, void *reserved)
{
return 1;
}
$ cat library.def
LIBRARY "library.dll"
EXPORTS
func0 @2
func1 @3
func2 @1
$ i686-w64-mingw32-gcc -c library.c -Os
$ ld -m i386pe -b pe-i386 -s -shared -o library.dll library.o library.def
Now examine exported symbols from the created dll library. As GNU binutils does
not provide a tool to show hint indexes of exported symbols from DLL library
(or at least I do not know which/how), show it via MSVC DUMPBIN.EXE tool:
$ dumpbin.exe /exports library.dll
...
ordinal hint name
20 func0 (1000)
31 func1 (1001)
12 func2 (1002)
As can be seen the GNU LD puts exported symbols into the DLL library in order
as they are specified in the DEF file. In this order they are also in the
Export name table, which provides the hint number.
Now create an import library from def file and link it with test executable.
$ cat test.c
__attribute__((dllimport)) void func0(void);
__attribute__((dllimport)) void func1(void);
__attribute__((dllimport)) void func2(void);
int mainCRTStartup(void)
{
func1();
func0();
func2();
return 0;
}
$ dlltool -d library.def -l library.a --as i686-w64-mingw32-as
$ i686-w64-mingw32-ranlib library.a
$ i686-w64-mingw32-gcc -c test.c -Os
$ ld -m i386pe -b pe-i386 -s -o test.exe test.o library.a
And inspect it via GNU objdump and readpe utility:
$ objdump -p test.exe
...
The Import Tables (interpreted .idata section contents)
vma:HintTime Forward DLL First
Table Stamp ChainName Thunk
3000 3028 306c 3038
DLL Name: library.dll
vma: Hint/Ord Member-Name Bound-To
30482 func0
30503 func1
30581 func2
$ readpe -i test.exe
Imported functions
Library
Name:library.dll
Functions
Function
Hint:2
Name:func0
Function
Hint:3
Name:func1
Function
Hint:1
Name:func2
As can be seen, hints of the symbols in test.exe do not match hints of the
exported symbols from the library.dll. Which indicates that the import library
contains incorrect hints (generated by dlltool).
Now I reverted commit 35fd2ddeb1d90f1750401cfb6d01fe055656b88d, re-run dlltool,
ranlib and ld. And inspection of the created test.exe shows:
$ objdump -p test.exe
...
The Import Tables (interpreted .idata section contents)
vma:HintTime Forward DLL First
Table Stamp ChainName Thunk
3000 3028 306c 3038
DLL Name: library.dll
vma: Hint/Ord Member-Name Bound-To
30480 func0
30501 func1
30582 func2
$ readpe -i test.exe
Imported functions
Library
Name:library.dll
Functions
Function
Hint:0
Name:func0
Function
Hint:1
Name:func1
Function
Hint:2
Name:func2
As can be seen now after reverting that commit
35fd2ddeb1d90f1750401cfb6d01fe055656b88d, hits in the test.exe matches the
hints in the library.dll as was shown by dumpbin.exe.
I'm not sure w
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #2 from Pali Rohár --- Hello Nick, I'm going to look at bug #20814 and bug #20880. And let you know. Anyway, what do you mean by "resolve both this PR" abbreviation? Because PR are initials of my name. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31738] New: Improve objdump -p output of PE Import and Export Tables
https://sourceware.org/bugzilla/show_bug.cgi?id=31738 Bug ID: 31738 Summary: Improve objdump -p output of PE Import and Export Tables Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org CC: nickc at redhat dot com Target Milestone: --- Created attachment 15520 --> https://sourceware.org/bugzilla/attachment.cgi?id=15520&action=edit Improve objdump -p output of PE Import and Export Tables For debugging #31728 #20814 #20880 I slightly improved objdump -p output of PE Import and Export Tables. Changes are attached. In the objdump -p output are now both import/export Ordinal numbers and Hint numbers. This allows more easier to check if the hint number of exported symbol from DLL matches the hint number for imported symbol into EXE (or another DLL). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/20814] DLLTool Put Wrong Hint Value In Lib Archieve (IDATA6 Section)
https://sourceware.org/bugzilla/show_bug.cgi?id=20814 Pali Rohár changed: What|Removed |Added CC||pali at kernel dot org --- Comment #8 from Pali Rohár --- This change in commit 35fd2ddeb1d90f1750401cfb6d01fe055656b88d broke generating hint indexes in import libraries from DEF file via dlltool. I filled a new bug #31728 for this issue. After applying revert of that commit on top of the current git branch of binutils, dlltool started generating correct hints indexes. I verified it by MS DUMPBIN tool and also by my changes to binutils objdump, which I put into the new bug #31738. The information here in this bug #20814 is on the wrong premise: In the attachment #9639 is comparision of **ordinals** from export library with the **hints** from the executable. Ordinals and hints are two different things without any relation between them and trying to match hints to ordinal is just an incorrect thing. In simple cases, which means that all symbols in input DEF files are lexicographically sorted, no symbol has explicit ordinal assigned then the symbols's ordinal == hint + 1. But in all other cases there is no relation at all. Seems that the MS "Properties" dialog shows only ordinal number. But MS tool "DUMPBIN.EXE /exports" shows both ordinal number and hint number. Executable can import symbol either by ordinal or by name+hint. Not both. So if the symbol is imported by name then the number is hint, not the ordinal. I explained it a bit more in the bug #31728. So based on the information in bug #31728 and improved objdump -p (#bug 31738) I would propose to revert the commit 35fd2ddeb1d90f1750401cfb6d01fe055656b88d. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #3 from Pali Rohár --- Hello Nick, For debugging this issue I created an improvement for objdump -p, see bug #31738. I wrote a new comment into bug #20814 with explanation and I think that Hint value in lib archive (= import library) generated by dlltool can be fixed just by reverting the commit 35fd2ddeb1d90f1750401cfb6d01fe055656b88d. I tried to explain all the things related to ordinals and hint numbers. If something is still not clear, please write which part. I will look at the bug #20880 later and let you know. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31738] Improve objdump -p output of PE Import and Export Tables
https://sourceware.org/bugzilla/show_bug.cgi?id=31738 --- Comment #3 from Pali Rohár --- Ok, feel free to modify it. I used it for debugging bug #31728, bug #20814 and bug #20880. Anyway, how to run that one exclude-symbols-def-i386.d test case? I can try to improve it, to validate both hint number and ordinal number. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30139] Incorrect ordinal numbers for aliased symbols in DEF file
https://sourceware.org/bugzilla/show_bug.cgi?id=30139 Pali Rohár changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Pali Rohár --- Some corrections. By default (unless NONAME is not specified in def file), import library imports symbol by name+hint (not by ordinal), .exe file imports by what is in import library, hence in this case by name+hint too. With recent changes in objdump (from bug #31738) to correctly shows ordinals and hints, now for the example from the description it shows: $ objdump -p test-ordinal.exe | grep -A 4 library.dll DLL Name: library.dll vma: Ordinal Hint Member-Name Bound-To 83880002 function 83900001 function So in the description of the bug report for provided example should have been written that incorrect HINT number was generated. Anyway, the problem is also for the exports by ordinals. Example is with the same commands and files as in the bug description, just the symbol "function" in the def file has "NONAME" keyword specified. $ cat library.def LIBRARY "library.dll" EXPORTS function @1 NONAME alias NONAME == function For this example the objdump prints: objdump -p test-ordinal.exe | grep -A 4 library.dll DLL Name: library.dll vma: Ordinal Hint Member-Name Bound-To 8388 2 8390 1 And this is a bug as in the def file there is no symbol with ordinal 2 specified. The application call / reference just the symbol "function" which has ordinal number 1. Wrong hint number is not a big issue (it just cause slower loading of application as the PE loader has to scan whole export table). But wrong ordinal number is a serious bug as it cause that application calls different function than it should. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #4 from Pali Rohár --- Hello Nick, I have check that reverting both 35fd2ddeb1d90f1750401cfb6d01fe055656b88d and 4ee1d7e401a8c1aedfdc86aac7faa8267eab1e5c commits on top of the master git branch fixes hints in import libraries generated by dlltool and ld. It can be verified by the objdump -p improvements done in bug #31738. So if there were any other issues than this issue then they were fixed. Nick, do you need some more information? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/20880] [LD] [Bug] Wrong Hint Value For ImportLib IDATA6
https://sourceware.org/bugzilla/show_bug.cgi?id=20880 Pali Rohár changed: What|Removed |Added CC||pali at kernel dot org --- Comment #13 from Pali Rohár --- Commit 4ee1d7e401a8c1aedfdc86aac7faa8267eab1e5c which was applied to the git repository broke generating of hint numbers in import libraries produced by GNU LD. Issue is same as described in another bug report comment: https://sourceware.org/bugzilla/show_bug.cgi?id=20814#c8 objdump -p improvements done in bug #31738 shows that hint numbers in the final executable linked with import lib generated by LD are really wrong after this change. So I would propose to revert this commit 4ee1d7e401a8c1aedfdc86aac7faa8267eab1e5c as it makes situation even worse. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/20814] DLLTool Put Wrong Hint Value In Lib Archieve (IDATA6 Section)
https://sourceware.org/bugzilla/show_bug.cgi?id=20814 --- Comment #9 from Pali Rohár --- Nick, the commit 35fd2ddeb1d90f1750401cfb6d01fe055656b88d should be reverted too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #5 from Pali Rohár --- Created attachment 15598 --> https://sourceware.org/bugzilla/attachment.cgi?id=15598&action=edit Improve documentation about Import Directory Table I attached a patch which improves documentation about Import Directory Table. It should help people with understadning of formats and differences between ordinal number and hint number. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #8 from Pali Rohár --- Yes, we are good now. I will try to prepare some automated test case which will cover both ordinal numbers and hint numbers. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31953] New: Show PE objdump -P versions in human readable form
https://sourceware.org/bugzilla/show_bug.cgi?id=31953 Bug ID: 31953 Summary: Show PE objdump -P versions in human readable form Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pali at kernel dot org Target Milestone: --- Attached changes improves PE objdump -P output of version fields. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31953] Show PE objdump -P versions in human readable form
https://sourceware.org/bugzilla/show_bug.cgi?id=31953 --- Comment #1 from Pali Rohár --- Created attachment 15599 --> https://sourceware.org/bugzilla/attachment.cgi?id=15599&action=edit Show PE objdump -P Linker version in human readable form -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31953] Show PE objdump -P versions in human readable form
https://sourceware.org/bugzilla/show_bug.cgi?id=31953 --- Comment #2 from Pali Rohár --- Created attachment 15600 --> https://sourceware.org/bugzilla/attachment.cgi?id=15600&action=edit Show PE objdump -P Win32 Version field -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31953] Show PE objdump -P versions in human readable form
https://sourceware.org/bugzilla/show_bug.cgi?id=31953 --- Comment #3 from Pali Rohár --- Created attachment 15601 --> https://sourceware.org/bugzilla/attachment.cgi?id=15601&action=edit Show PE objdump -P versions in more human readable form Show major and minor versions at one line. Parse Win32 version parts (major, minor, build and platform). Change names to match their meaning: - Image version is the version of the application / binary itself (can be anything) - Subsystem version is the minimal required subsystem version which has to be supported by host system - OS version is the minimal required OS version which has to be supported by host system - Win32 version is the OS version which host system would overwrite and report to application at runtime -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #9 from Pali Rohár --- Created attachment 15620 --> https://sourceware.org/bugzilla/attachment.cgi?id=15620&action=edit ld/testsuite: Improve PE exclude-symbols-* tests -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #10 from Pali Rohár --- Created attachment 15621 --> https://sourceware.org/bugzilla/attachment.cgi?id=15621&action=edit ld/testsuite: Add PE tests for Ordinal and Hints in PE Export Table generated by ld -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #11 from Pali Rohár --- Created attachment 15622 --> https://sourceware.org/bugzilla/attachment.cgi?id=15622&action=edit ld/testsuite: Add PE tests for Ordinal and Hints in PE Export Table generated by dlltool -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #12 from Pali Rohár --- Created attachment 15623 --> https://sourceware.org/bugzilla/attachment.cgi?id=15623&action=edit ld/testsuite: Add PE tests for Ordinal and Hints in PE Import Table generated by dlltool -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #13 from Pali Rohár --- Created attachment 15624 --> https://sourceware.org/bugzilla/attachment.cgi?id=15624&action=edit ld/testsuite: Add PE tests for Ordinal and Hints in PE Import Table generated by ld -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #14 from Pali Rohár --- I attached 5 changes which add PE tests for ordinal and hints for both PE Export and PE Import tables. For both dlltool and ld. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31953] Show PE objdump -P versions in human readable form
https://sourceware.org/bugzilla/show_bug.cgi?id=31953 Pali Rohár changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #4 from Pali Rohár --- Nick, could you please look at these PE objdump -P changes? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #15 from Pali Rohár --- Hello Nick, have you looked at those test cases? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #18 from Pali Rohár --- What are steps needed to reproduce this problem? Because is working for me with ./configure --target=i686-w64-mingw32 -- You are receiving this mail because: You are on the CC list for the bug.
