From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) by sourceware.org (Postfix) with ESMTPS id 4F8A13858D1E for ; Wed, 3 May 2023 00:51:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4F8A13858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-192a0aab7dfso313550fac.3 for ; Tue, 02 May 2023 17:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683075077; x=1685667077; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=uNzxrlaTuUk6X6W6c5AZxjUrHhO9MICE2iDXVewnIig=; b=XHV04Ot0LXvkO7Y+VhN9JAvLCwitC/DAHfbHhzOejvs5kgPJWGCTeUyrZUnW2bWhIE S2qUgPlBC5/6nuvxxvLNPfxDkoGtQ6Hf6H/a4kZGE0s7MvleCwawlhTMe+Om8SzCGnrP 0rI/bi9u1bxKFQQHhMBW9et4E89ikMH2DEvsGHz/BmUGFlA2trsN9vJd73TbV0j73+4I Zby/DRTHLloz8+9xzR2pGbeeTwrClR8DN2tLCN4TN0NmQ324EoT7eALLH3Kb7srrnUxK wDAsk1mWVm1XgVH6dQAeuCzvjLwwR231sMOqKcsOF2pj4LTyZisAJfnYXSI/EkyyW/Y4 Q+6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683075077; x=1685667077; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uNzxrlaTuUk6X6W6c5AZxjUrHhO9MICE2iDXVewnIig=; b=RreBLaW/uOYiEzrGPV0mpyYYHAyu9WHo3E3cUL13o4Yh30NMgpoyCE3mirddtv+k8q XqkAvINbyB1Ge86q4G2W9nVMmnTWKUpRcBfWJV8VoYVjQ3pVOAn9zyhKhIImSXwa98Q7 yRSi22Mh0oy6A6eYaEjNVn2GK/C38E92YwRnDpScJI6GkqNDtxG3h/78pThCTQ+0rYEv D638MUZO5xQddG8E4qnE1UKaBGGgoNggeLjw00GYyRvMDogtUN1gf9SJMnSTZjMsDsLx 8RkbOhzheosjdC/J1aNnN2BymS5B7HtvGqrBM/GUDYavOKtXG17/cB4Cj3QiNbGnmwPS +LTg== X-Gm-Message-State: AC+VfDx01V99TsIE08AzmaH6QluFFrpV73sYvQ5cPclz4/loqmPNfTfh WFWW3i/zDmg7hPbvkEoOKlVFzEBwKIHfgSU58vUIWkUP X-Google-Smtp-Source: ACHHUZ5rD7Smc6t7w1go6/ekngnbpd2LHhyuedQgX5NaZ7oKnielx1mJOJksX+k3sUGSrAyp0v7Z+rWhVUzeA5emJGo= X-Received: by 2002:a05:6870:9541:b0:17a:cabc:c92c with SMTP id v1-20020a056870954100b0017acabcc92cmr9620245oal.4.1683075077403; Tue, 02 May 2023 17:51:17 -0700 (PDT) MIME-Version: 1.0 From: Tom Kacvinsky Date: Tue, 2 May 2023 20:51:06 -0400 Message-ID: Subject: ld --base-file option, dlltool generated exp files To: Binutils Content-Type: multipart/alternative; boundary="0000000000001e76b605fabf7472" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000001e76b605fabf7472 Content-Type: text/plain; charset="UTF-8" HI, I have an interesting issue I am facing. On Windows 10, using a custom built MinGW-w64 toolchain, based on binutils 2.38, the mingw-w64-crt v10.0.0 with UCRT support, and GCC 12.1.0. This also happens with binutils 2.40 and the MinGW-w64 run time version v11.0.0 (recently released). Of note, binutils 2.30 (ancient, I know), doesn't have this problem. We use the GNAT portion of GCC for compiling our Ada code, and use gnatdll for producing the DLL of our Ada code. What I found through lots of experimentation is that either the base file generated by ld or the exp file generated by dlltool is off and is making a DLL that causes our applications to crash when run with Microsoft's Application Verifier. The steps I've been following are laid out in the gnatdll user guide https://gcc.gnu.org/onlinedocs/gnat_ugn/Using-gnatdll.html Except I pass "-g -Wl,-v" to the -largs option of gnatdll so that gnatlink keeps the binder file around and gives me the exact ld invocation. I then manually follow the steps, but by invoking the three linker commands and two dlltool invocations as as they would be if I ran everything though gnatdll. The reason I say it's either the base file or the exp file is that I can take my export definition file (a .def file) and generate an import library and exp file using Microsoft's lib tool, and that exp file makes the final link produced a DLL that does not have an issue. So I _suspect_, but am not sure, that either the base file generated by ld using the --base-file option is not right, and so dlltool produces an exp file that isn't quite right, or perhaps the base file is right, but dlltool is still generating an exp file that has problems. I looked for commits in bfd/cofflink.c (where the .base file would be generated) and also looked at commits to dlltool, but nothing stood out. But then I am not a binutils expert. I have a way around the problem without using a base file (just pass the .def file directly to ld so that an export table is generated), but I wanted to report this issue. What would be most useful for a reproducer? I think I am going to have a difficult time paring our code down to an MRE, and I'm reluctant to release IP object code (I can run that up the flagpole, tough). Any help would be much appreciated. Regards, Tom --0000000000001e76b605fabf7472--