public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Oleg Tolmatcev <oleg.tolmatcev@gmail.com>
To: binutils@sourceware.org
Subject: [PATCH] ld: fix 32-bit mingw DLL symbol export bug
Date: Tue, 26 Dec 2023 15:24:56 +0100	[thread overview]
Message-ID: <CACcXsZhhhPOfk_q9WBwOpiV1+djV7Unkys7dV0Y_c4CVdyZ7ag@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

Hello,

I think there's a bug in ld on 32-bit Windows.Here is a tiny project
for reproducing the problem. https://github.com/oltolm/ld-mingw32-bug

A 32-bit DLL exports two stdcall functions "myfunc" and "myfunc64".
The functions would normally get exported as "myfunc@0" and
"myfunc64@0". The "DEF" file exports them as "myfunc" and "myfunc64"
without the decorations. When you run the executable it shows an error
message saying that it can not find "myfunc64". I think it happens
because the sorting in ld is wrong.

I think it should use the exported names "myfunc" and "myfunc64", but
instead it uses the decorated names "myfunc@0" or "myfunc65@0". The
ordering of functions in the DLL is different depending on which names
you use.

My patch changes ld to use undecorated exported names for sorting and
it seems to fix the problem. When I execute ctest in my project, it
runs successfully.

[-- Attachment #2: 0001-ld-fix-32-bit-mingw-DLL-symbol-export-bug.patch --]
[-- Type: application/octet-stream, Size: 948 bytes --]

From c5ffcde3277e3aec48f0f1f2689fd628b3972d2f Mon Sep 17 00:00:00 2001
From: oltolm <oleg.tolmatcev@gmail.com>
Date: Tue, 26 Dec 2023 14:42:39 +0100
Subject: [PATCH] ld: fix 32-bit mingw DLL symbol export bug

Signed-off-by: oltolm <oleg.tolmatcev@gmail.com>
---
 ld/deffilep.y | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/ld/deffilep.y b/ld/deffilep.y
index 33c8cf35c5..45f90306e3 100644
--- a/ld/deffilep.y
+++ b/ld/deffilep.y
@@ -610,12 +610,11 @@ cmp_export_elem (const def_file_export *e, const char *ex_name,
 {
   int r;
 
-  if ((r = are_names_equal (ex_name, e->name)) != 0)
+  if ((r = are_names_equal (its_name ? its_name : ex_name,
+			    e->its_name ? e->its_name : e->name)) != 0)
     return r;
   if ((r = are_names_equal (in_name, e->internal_name)) != 0)
     return r;
-  if ((r = are_names_equal (its_name, e->its_name)) != 0)
-    return r;
   return (ord - e->ordinal);
 }
 
-- 
2.43.0.windows.1


             reply	other threads:[~2023-12-26 14:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-26 14:24 Oleg Tolmatcev [this message]
2024-01-16 20:40 ` Oleg Tolmatcev
2024-01-19 11:40   ` Nick Clifton
2024-01-19 12:34     ` Oleg Tolmatcev
2024-01-19 15:06       ` Nick Clifton
2024-01-19 16:07         ` Oleg Tolmatcev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACcXsZhhhPOfk_q9WBwOpiV1+djV7Unkys7dV0Y_c4CVdyZ7ag@mail.gmail.com \
    --to=oleg.tolmatcev@gmail.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).