From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by sourceware.org (Postfix) with ESMTPS id 9CF123858C60 for ; Mon, 20 Dec 2021 16:49:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9CF123858C60 Received: by mail-qt1-x835.google.com with SMTP id o17so10349190qtk.1 for ; Mon, 20 Dec 2021 08:49:13 -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:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=7mWAMuXS0sCwf6V/JNhiJk63EmWRDytv4ajRQiOKefA=; b=GUwGe5xvpWKatKEggxwyjryz/7Y1rwUjMfIdhCGwCHqqmCZnz6xf7OUrxtxoA2lhiK delrZJayjLs52KJ+W2N2NM62YBcQ6zCwR3sKk5NQ0eRQT+lCbSOiySqyOu1joEMVD+s+ rzOs814JG8nNQpgu78WzEGARcdWJTK+OlrCxwizg94pZCI/luKIw5/265/QN+yYB+az1 KYKkWMghjynMTtJlnD3Y/Y7JqJEn7nn5GQbLIxFv/4zDPGm/lbb0Vsjj0gCeIvInkyXy +kjWXtqAvudFI6K7uK5B4kZ+XVqH8AzorqhJWzQd3ZvXDMs+ELIQgH0BeavhydmXwAL0 +92A== X-Gm-Message-State: AOAM532cBheYCz5IzabL3EjCWxhfAh5aJhuC53OcJeEs/lYYdQecHLtr 2QNepDcd40hsJt2BzVPRnKO3gxXdMtstxA== X-Google-Smtp-Source: ABdhPJyI2AQHQdfm/3NBtmcYDBpJpINPtQasvIXXFRbDafhdx5Kitk3SlCIplKaeD1k+jsL2clDnlQ== X-Received: by 2002:ac8:59c5:: with SMTP id f5mr13143140qtf.135.1640018953165; Mon, 20 Dec 2021 08:49:13 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:3b1e:762b:24f5:94b:4e15? ([2804:431:c7cb:3b1e:762b:24f5:94b:4e15]) by smtp.gmail.com with ESMTPSA id w9sm11848373qko.71.2021.12.20.08.49.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Dec 2021 08:49:12 -0800 (PST) Message-ID: Date: Mon, 20 Dec 2021 13:49:10 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v6 15/20] elf: Run constructors if executable has a soname of a dependency Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org, John Mellor-Crummey , Ben Woodard References: <20211115183734.531155-1-adhemerval.zanella@linaro.org> <20211115183734.531155-16-adhemerval.zanella@linaro.org> <874k75he1l.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <874k75he1l.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2021 16:49:18 -0000 On 18/12/2021 17:08, Florian Weimer wrote: > * Adhemerval Zanella: > >> The DSO constructor should not be ignored if the main executable >> has the SONAME set to a dependency. It fixes the case where >> (using the scripts/dso-ordering-test.py definition): >> >> {}->a->b->c;soname({})=c >> >> Where the constructors should return >> >> c>b>a>{} > I'm a bit unclear what is this trying to fix. The issue is tst-dso-ordering11 sets its SONAME as one of its NEEDED objects: $ readelf -d t st-dso-ordering11 | grep 'SONAME\|NEEDED' 0x0000000000000001 (NEEDED) Shared library: [[...]/tst-dso-ordering11-dir/tst-dso-ordering11-a.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [[...]/tst-dso-ordering11-dir/tst-dso-ordering11-a.so] And then the tst-dso-ordering11-a.so constructor is skipped. > > It reminds me of this change: > > commit 9ffa50b26b0cb5d3043adf6d3d0b1ea735acc147 > Author: Florian Weimer > Date: Fri Dec 11 17:30:03 2020 +0100 > > elf: Include libc.so.6 as main program in dependency sort (bug 20972) > > _dl_map_object_deps always sorts the initially loaded object first > during dependency sorting. This means it is relocated last in > dl_open_worker. This results in crashes in IFUNC resolvers without > lazy bindings if libraries are preloaded that refer to IFUNCs in > libc.so.6: the resolvers are called when libc.so.6 has not been > relocated yet, so references to _rtld_global_ro etc. crash. > > The fix is to check against the libc.so.6 link map recorded by the > __libc_early_init framework, and let it participate in the dependency > sort. > > This fixes bug 20972. > > Reviewed-by: Carlos O'Donell > > Is it a more general/correct version of this commit? I think it is unrelated. > > But if the main program has a soname, wouldn't we stop loading it as a > dependency, too? So that the expected ouptut turns into: > > b>a>{} > because the separate c is not actually loaded. Right, so if the idea is indeed to not load an dependency that matches the binary SONAME current behavior is indeed what is expected. Not sure if this the expected behavior, if so I will drop this patch.