From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 433BD3858D28 for ; Wed, 15 Dec 2021 13:12:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 433BD3858D28 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-396-86-1jGPIOk2MyviZqOi-Rw-1; Wed, 15 Dec 2021 08:12:35 -0500 X-MC-Unique: 86-1jGPIOk2MyviZqOi-Rw-1 Received: by mail-wr1-f72.google.com with SMTP id b1-20020a5d6341000000b001901ddd352eso5947682wrw.7 for ; Wed, 15 Dec 2021 05:12:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to :content-transfer-encoding; bh=Jz/jBoJaUtBdVReMMcHcTAqoAu4/v48CvikspWP7Pzo=; b=uQXGznIpURwK46Ji2WSNyRgmdF/BUQ/P/W5ZagmMPw2cVLWjWq30sdN0Ar5PRDMvQO SYX9QUjeDTkAB/2kXpNmw+AccsJEDeYZFf3JzCtrFfcfbbHoCBBOQR77GXA7FoAKrk8z q4TFKe6aecvsYhkyV/Zmex4lDnzBTB+EmaIlLaA/iPdqBiwRU4PSVk0fX0V8wZ2T+VI1 Uwlxelr2sr1ktMMHWc9hjRhFXt9OZ8hAhjB0f/nIzFczXrN4DpzIDlUA+RdlIyW97ifG KT/3+guQYLJ6SkBaH9VplcmVdetIxbKfEyTCesyMW9mrNNVXLPcVhaU7Z6rD5lZrTe6C ESoQ== X-Gm-Message-State: AOAM533BUwzYLvpUlJWWlIhR2iCT08xKS14ARf2knYA0mW2x6pRjD6+i 9YKI4C3wksLty3gzwhxWbP4DXA7ULmPQAuqU/J8J9sZSxPFkXCe1bp4lzXvgS2+NhPtSkkEs3ec jX8yBe+3sk4218eejZQ== X-Received: by 2002:adf:e742:: with SMTP id c2mr4402852wrn.498.1639573953954; Wed, 15 Dec 2021 05:12:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZW9A0s2VoYdACCo488LxOzqQJaZuNqELp6yHdPtI3TjrKdAfFsoYvDN0Yz12Yepoy9BwlxA== X-Received: by 2002:adf:e742:: with SMTP id c2mr4402837wrn.498.1639573953765; Wed, 15 Dec 2021 05:12:33 -0800 (PST) Received: from [192.168.1.6] (adsl-164-239.freeuk.com. [80.168.164.239]) by smtp.gmail.com with ESMTPSA id n36sm3939734wmr.2.2021.12.15.05.12.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Dec 2021 05:12:33 -0800 (PST) Message-ID: Date: Wed, 15 Dec 2021 13:12:32 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 To: Achim Gratz , binutils@sourceware.org References: <878rwvrlz9.fsf@Rainer.invalid> From: Nick Clifton Subject: Re: [Bug] DWARF-5 section names in PE/PEP and weak symbols In-Reply-To: <878rwvrlz9.fsf@Rainer.invalid> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 13:12:44 -0000 Hi Achim, Please could you file a bug report for this problem here: https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils > changed the behaviour of weak symbols in Cygwin. The following test > from gnulib that should fail. In other words fputs should have a symbol > value of 0x0 and the resulting executable should not be able to run > since the Windows loader does not resolve weak symbols): > > --8<--weak.c-------cut here---------------start------------->8--- > #include > #pragma weak fputs > int main () > { > return (fputs == NULL); > } > --8<---------------cut here---------------end--------------->8--- > > $ gcc -o weak weak.c # w/ binutils 2.36.1 > $ ./weak ; echo $? > ./weak: ./weak: cannot execute binary file > 126 > > Instead, starting with the above commit, the test succeeds since fputs > has the (expected) value from cygwin1.dll. So you are saying that because the linker script now includes specific references to DWARF-5 debug sections, the fputs symbol is being pulled in to the link from the cygwin1.dll and hence it is no longer undefined ? That seems to be most strange. > I've narrowed it down to just one of the new DWARF5 sections and > removing them from the linker scripts restores the correct behaviour of > weak symbols in Cygwin (I have no idea if that triggers problems > elsewhere): > +/* === > .debug_loclists ${RELOCATING+BLOCK(__section_alignment__)} ${RELOCATING+(NOLOAD)} : > { > *(.debug_loclists) > } > +=== */ Hmm, I suppose that the location lists will refer to real locations in the code space, and so including the debug information could also pull in the code itself. But really you would only want to have the debug information for code that is already part of the final link. So maybe the underlying problem is that the debug information has not been pruned to match discarded code. Quick question - if instead of deleting the references to the .debug_loclists section you move them into the /DISCARD/ section earlier in the pe.se file, does this also solve the problem. (The point being that if the script explitcitly discards this information we also have room to add a comment explaining why. Plus it will prevent future changes to the pe.sc file from adding the section back in). (Also the change would be needed in the pep.sc file as well, obviously. Plus the .zdebug_loclists section would need similar treatment). Cheers Nick