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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id ABC3E3857C5F for ; Wed, 16 Sep 2020 17:10:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ABC3E3857C5F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-314-bZ4Hk2WPOLmkxeakfF87QQ-1; Wed, 16 Sep 2020 13:10:03 -0400 X-MC-Unique: bZ4Hk2WPOLmkxeakfF87QQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 18972109106C; Wed, 16 Sep 2020 17:10:02 +0000 (UTC) Received: from localhost.localdomain (ovpn-114-39.phx2.redhat.com [10.3.114.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id D327E60BFA; Wed, 16 Sep 2020 17:10:01 +0000 (UTC) Subject: Re: Problem with static const objects and LTO To: "H.J. Lu" Cc: GCC Patches References: <8770b080-9da3-e8e5-80a7-afde36ab3e5e@redhat.com> From: Jeff Law Message-ID: Date: Wed, 16 Sep 2020 11:10:01 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0.0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------C1C608C5D7F5DFFD59D72674" Content-Language: en-US X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 17:10:06 -0000 This is a multi-part message in MIME format. --------------C1C608C5D7F5DFFD59D72674 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/16/20 11:05 AM, H.J. Lu wrote: > On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches > wrote: >> >> Consider a TU with file scoped "static const object utf8_sb_map". A >> routine within the TU will stuff &utf8_sb_map into an object, something >> like: >> >> fu (...) >> >> { >> >> if (cond) >> >> dfa->sb_char =3D utf8_sb_map; >> >> else >> >> dfa->sb_char =3D malloc (...); >> >> } >> >> >> There is another routine in the TU which looks like >> >> bar (...) >> >> { >> >> if (dfa->sb_char !=3D utf8_sb_map) >> >> free (dfa->sb_char); >> >> } >> >> >> Now imagine that the TU is compiled (with LTO) into a static library, >> libgl.a and there's a DSO (libdso.so) which gets linked against libgl.a >> and references the first routine (fu). We get a copy of fu in the DSO >> along with a copy of utf8_sb_map. >> >> >> Then imagine there's a main executable that dynamicly links against >> libdso.so, then links statically against libgl.a. Assume the main >> executable does not directly reference fu(), but does call a routine in >> libdso.so which eventually calls fu(). Also assume the main executable >> directly calls bar(). Again, remember we're compiling with LTO, so we >> don't suck in the entire TU, just the routines/data we need. >> >> >> In this scenario, both libdso.so and the main executable are going to a >> copy of utf8_sb_map and they'll be at different addresses. So when the >> main executable calls into libdso.so which in turn calls libdso's copy >> of fu() which stuffs the address of utf8_sb_map from the DSO into >> dfa->sb_char. Later the main executable calls bar() that's in the main >> executable. It does the comparison to see if dfa->sb_char is equal to >> utf8_sb_map -- but it's using the main executable's copy of utf8_sb_map >> and naturally free() blows us because it was passed a static object, not >> a malloc'd object. >> >> >> ISTM this is a lot like the problem we have where we inline functions >> with static data. To fix those we use STB_GNU_UNIQUE. But I don't see >> any code in the C front-end which would utilize STB_GNU_UNIQUE. It's >> support seems limited to C++. >> >> >> How is this supposed to work for C? >> >> >> Jeff >> >> > Can you group utf8_sb_map, fu and bar together so that they are defined > together? They're all defined within the same TU in gnulib.=C2=A0 It's the LTO dead/unreachable code elimination that results in just parts of the TU being copied into the DSO and a different set copied into the main executable.=C2=A0 In many ways LTO makes this look a lot like the static da= ta member problems we've had to deal with in the C++ world. jeff --------------C1C608C5D7F5DFFD59D72674 Content-Type: application/pgp-keys; name="pEpkey.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFkbIO8BCACVIqDhDVh9ur8C+zNV1J/cXfwvVDAUcphDEFl4jyHqZORK4Pd3 Db8oWqLmQ8lOCr/VOS7lrCtdpVMQkLGOGA16oJ8g7hzhnojpjY09UjsoUiG7oKac uxj8skfp6SIx93Zl+iNYPRa4S+za6nY8qiVjyUuiyX04ZPZMrKp2c2sGi+HnBKUZ XGhrz/Jdzdox3tjajWZnObyynhEN6hn9L3KawTtGPE/R6A/1RhHTD9FQmIWIeucp aY5c6GNKXTFpj2VYx57LY5hve1R5vhrJIZcgwZAiOtmik5lVi96glY5h6bugRwpe xjhwORTLPBCkwiYotSxX99mWd6EHL576i5CNABEBAAG0GUplZmYgTGF3IDxsYXdA cmVkaGF0LmNvbT6JAU4EEwEIADgWIQR+niGjtnP5P/8PpRq8fP682pgzWwUCWRsg 7wIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRC8fP682pgzW5QGB/9VATJm x5235RB+8jiDYGXQf3vd9gBfPy/l1tsaK400eFAevDzfGvKmeCKe+uGnlrH3vyT8 rg9zqH+s5a1Y+lDXPOpJAFmmzbOLU4FW4ucbawmtYvBL65PqpQneCTYnC802/OAc xjm/OnemHlgeK6WicNsBTPwYN/0araDFUejyYBIFi9CNqqflwk5Z3brKbQ9bAYIk ysVLC/c3njKPmM0cWPFHG91ubLbWCHwTIK0+mAL714eTD74dXzOjO2ZDBPLGlFN/ kO3+YjaO6UOD2O8acvAMCivTkWLr7JwRgLIQDN2DkhQDd3LTPqQE/yOcMcXBTO+f xm8KG0iKQBqWMyGJuQENBFkbIO8BCACyqbOsv7XegSeea8XORt5zMaBVWKoSyhmm cCmlxZFS2cuYOBt79MO13lZE2DlO3Lv5IKikj/D4ketGVO4+h5psEMH5Yz5P8bx0 TmgwbK1GxPZrzeXozUFJDvvCDbIlT0v0pwUXuK3hg8Ieo2h5uTed/cn1OjySXW5B qLxN0cyr5hL+J6dcsHvKLT/N3nTgCQhoJXK2MrEMhAGgF3jKpMn3CoS4i/ZbNI2M QR6LWHwdZ95f0fI8NzHSfVzeLtzCKQec7nr9fgd6Ylk1ZpGWQUPlQmKjzYgeCeTK NO04cwt20WIrQWeWiZFPA0U86NDBdSBrYp4kG3dfIXE+wSSvE7qPABEBAAGJATYE GAEIACAWIQR+niGjtnP5P/8PpRq8fP682pgzWwUCWRsg7wIbDAAKCRC8fP682pgz W3REB/9cT7iKRPg/OK9bpLlllIEDM90IaKC79DQrv+fRudOR78cdV4XUwPSFnyHU sP3VJ4lDy5FhiKCwGie0BK53EsxgMrLy1L8hboFdTE4Vi0xzCheMaMVp4hATDU29 k1cuxu1VPpCa8E3mYeHjNV7ip0HN5L4Drfs8lRPJE/oM1vGs9DgQFZrCPPNRNGKC 97BH+DHccesEJr7tSsQrkPkt0z/FTKr5wIM02vSxOJjgmcVbGB7dc2j/Sx8loXmu KnuKtM35668kUG8jeJvSQk3o/VHpD27bhl0rR68R2jN6G6kQegMVb6dPu1Ius8rB E5rFw88J4JEb5q4hMNClWWUFHIdP =3DIDHe -----END PGP PUBLIC KEY BLOCK----- --------------C1C608C5D7F5DFFD59D72674--