From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) by sourceware.org (Postfix) with ESMTPS id EB79A3858C74 for ; Sun, 14 May 2023 18:45:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EB79A3858C74 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-x30.google.com with SMTP id 586e51a60fabf-195ee1be41aso7116169fac.1 for ; Sun, 14 May 2023 11:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684089901; x=1686681901; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=v3Usisb0gwFPnpWemVv0Gi97iS9U45OIX9OD9hED0iw=; b=qaT4V0Lmi+H9NcGYlVPDLJVkBa4Iv0xRNl+yGyf13+17/OMcK8HLvREiqv1Um0az6b s/NDqMNdY9NRCw6rxn8bKzKALlPQ1nUdpvRMP2POvEGu1883xzVDmR/18WMaX4XxwOjp Gcwd4xTCL3KI2ppqPwrLx95S7LBdzLRGvmvs9D3TYtPbkDk8Inq+8nKvYPKFfhJGwOrb Hgmxjom3uAiDAaD0DoWO7UCfPTReOSHY4EoN4mQHjn8+c1zpaXtFG7FT3stNc4hP1L4J IudKrZJbhWlcsfSLTeHi+juXSe9Duf6pAQUB3TE5PFm4zGAG9Svzs6xkQmbJn0HLOfeU WsyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684089901; x=1686681901; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=v3Usisb0gwFPnpWemVv0Gi97iS9U45OIX9OD9hED0iw=; b=K7vqyyJRKVGSvtLKDT0ORioRSuyT3pyaqWic+J3HM4ctQnWd/bXmP0LUmweBRUrTl5 yKfZdgv0Mkl+VivhGOw+dYQhIoRSpM/x5+szuHdY2JnvIhkGAoQnw5yNjTAzACOoKBdr h3q48+fzM5IwMNrrQeSW0BzxQNJOSIdwobGTBPvMVL3op9T8q8JmD69sEff2WQggnjF7 D4gYRc+emoJUGU+Xrro2CZ8WBw9Shiv5Cnoi86hGjMS6Np3ETC0DwnYma+x0edAClpvg fCsBPzopdFWEPE5CL4jImD0s6jE+8f43zMtxElBZ7zaqy7fIvtWQVIwe5C3LxYMmC7BU M2VQ== X-Gm-Message-State: AC+VfDxwY9Ibs3ntJox59nHw9Q91e80cbx2bcJXAOURnuuipOElLf25q OXepOKddPy+gEH+RRlCa0NXSShCKql7tvwNjfVeHZLEl X-Google-Smtp-Source: ACHHUZ5i6vm8Ob8SXbFBWyHTQKSRw6LfkA1J+uJoD/+0YeVKsgtI3E6nCPkF9JeaN5ENQp/bIzVmgT31XHAEs0VCw70= X-Received: by 2002:a05:6870:8643:b0:188:1096:246f with SMTP id i3-20020a056870864300b001881096246fmr13776754oal.29.1684089900966; Sun, 14 May 2023 11:45:00 -0700 (PDT) MIME-Version: 1.0 References: <831c6d67-e502-1cb2-b68c-956c354c968b@redhat.com> In-Reply-To: <831c6d67-e502-1cb2-b68c-956c354c968b@redhat.com> From: Tom Kacvinsky Date: Sun, 14 May 2023 14:44:50 -0400 Message-ID: Subject: Re: ld --base-file option, dlltool generated exp files To: Binutils Content-Type: multipart/alternative; boundary="0000000000005128f905fbabbc82" X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,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: --0000000000005128f905fbabbc82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi NIck, On Wed, May 10, 2023 at 7:38=E2=80=AFAM Nick Clifton wro= te: > Hi Tom, > > > What I found through lots of experimentation is that either the base fi= le > > generated by ld or the exp file generated by dlltool is off and is > making > > a DLL that causes our applications to crash > > > 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 produce a DLL that does not have an issue. > > > 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. > > Thank you for doing this. It always helps when problems are reported, ev= en > if we do not have a solution available. > > Please could you file a bug report here: > > https://sourceware.org/bugzilla/enter_bug.cgi?product=3Dbinutils > > I haven't yet done so as I am fighting getting at least the major versions of binutils between which things broke. I think that would help to have in the bug report. But it appears it is going to be more involved than I thought. I thought I was going to get away with building all of our code with one binutils (using the version of binutils I know works) and then just swapping versions of binutils used for making the DLL until I find the version that broke. But that process ends up producing a DLL Windows does not like. :-(. So, I have to build the entire GCC + binutils toolchain, with the binutils version changing and GCC remaining fixed. This will take a while. It also doesn't help that my MSYS2 + MinGW-w64 installation doesn't like building 2.34 and 2.35 (before and after those versions, things are fine). It is a hang generating the files from pep.em and associated input files and scripts. > > > 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 > > Understood. A stand alone reproducer would be ideal, but if that is not > possible then some further details on the problem would definitely help. > For example - are you able to identify what is wrong the the DLLs being > produced by the linker ? Do any of the various PE-file checker programs > that are out there report any problems ? > I have reason to believe the problem is with relocations based on the .base and .exp files, but I don't know if a PE checking program can validate relocation information. I'll have to look into this. > Also - do you know if they problem happens with older versions of the > binutils, eg 2.35 or 2.36 ? Possibly the problem is due to a (relatively) > recent change to the linker. > See above - I am trying to figure this out. > I cannot make any guarantees, but I will definitely look at any bug repor= ts > you file. Thanks, Tom --0000000000005128f905fbabbc82--