From: Chung-Lin Tang <chunglin_tang@mentor.com>
To: Carlos O'Donell <carlos@redhat.com>, <cltang@codesourcery.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Ping x2 Re: [PATCH 1/2][RFC] #17645, fix slow DSO sorting behavior in dynamic loader
Date: Mon, 25 Nov 2019 09:19:00 -0000 [thread overview]
Message-ID: <1d9f8b04-3133-0e4f-c8a8-ff202db1339c@mentor.com> (raw)
In-Reply-To: <65a2cd71-8ad5-9122-a8cc-a54e8fbe89b5@mentor.com>
Ping?
On 2019/11/14 5:58 PM, Chung-Lin Tang wrote:
> On 2019/10/31 9:13 PM, Carlos O'Donell wrote:
>> On 10/8/19 2:22 AM, Chung-Lin Tang wrote:
>>> Ping again.
>>
>> I have these applied and I'm putting this through testing.
>
> Hi Carlos,
> Thanks for the testing, wonder how it went?
>
> Thanks,
> Chung-Lin
>
>>> On 2019/9/17 5:55 PM, Chung-Lin Tang wrote:
>>>> Ping?
>>>>
>>>> On 2019/7/21 1:50 AM, Chung-Lin Tang wrote:
>>>>> Hi, this patch is our attempt at resolving the slow shared object sorting
>>>>> situation in #17645, #15310, and some effort at #15311. I realize this is
>>>>> pretty unsuitable timing to be submitting a patch of such nature now (probably
>>>>> way too late to be included into 2.30), but still sending now anyways as this
>>>>> will probably need quite some discussion before being approved.
>>>>>
>>>>> Prior attempts at solving this slow sorting behavior appeared to have failed
>>>>> due to inadequate proposed testing, therefore cannot convince reviewers to
>>>>> touch what seems to be perceived as a sensitive and easy to break part of ld.so.
>>>>>
>>>>> Therefore the first part of this patch is not a change to the dynamic loader
>>>>> code proper, but a testing framework for constructing DSO sorting tests.
>>>>> It consists of a new Python script 'dso-ordering-test.py' that serves to
>>>>> generate both testcase source files and the needed Makefile fragments from
>>>>> a short description string, for example:
>>>>>
>>>>>      a->b->c->d         // four objects linked one after another
>>>>>
>>>>>      a->[bc]->d;b->c    // a depends on b and c, which both depend on d,
>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â // b depends on c (b,c linked to object a in fixed order)
>>>>>
>>>>> Â Â Â Â Â a->b->c;{+a;%a;-a}Â // a, b, c serially dependent, main program uses
>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â // dlopen/dlsym/dlclose on object a
>>>>>
>>>>> Â Â Â Â Â a->b->c;{}!->[abc]Â // a, b, c serially dependent; multiple tests generated
>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â // to test all permutations of a, b, c ordering linked
>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â // to main program
>>>>>
>>>>> Â Â Â Â (Above is just a short description of what the script can do, more
>>>>> Â Â Â Â Â documentation is in the script comments.)
>>>>>
>>>>> and, a patch to glibc/elf/Makefile which uses this script to add a few
>>>>> DSO sorting testcases. The description string notation and output form of the
>>>>> generated testcases is short enough that both the test descriptions
>>>>> and expected outcomes can all directly be specified in the Makefile.
>>>>>
>>>>> In terms of the tests I added using this script, I am not completely sure they are
>>>>> (together with existing tests) adequate to prove algorithmic integrity in face
>>>>> of any ld.so code changes, but the script should provide a solid tool to further
>>>>> improve on coverage. Also welcome suggestions if the current features are still
>>>>> lacking in expressing some case of shared object relations, or if the documentation
>>>>> still feels unclear.
>>>>>
>>>>> Thanks,
>>>>> Chung-Lin
>>>>>
>>>>> 2019-07-20 Chung-Lin Tang <cltang@codesourcery.com>
>>>>>
>>>>> Â Â Â Â Â Â Â Â Â [BZ #17645]
>>>>> Â Â Â Â Â Â Â Â Â [BZ #15311]
>>>>> Â Â Â Â Â Â Â Â Â [BZ #15310]
>>>>> Â Â Â Â Â Â Â Â Â * elf/Makefile (test_dso_ordering): New make function.
>>>>> Â Â Â Â Â Â Â Â Â (tst-dso-ordering[123456789]): Define new DSO sorting tests.
>>>>> Â Â Â Â Â Â Â Â Â (tst-bz15311): Testcase from #15311.
>>>>> Â Â Â Â Â Â Â Â Â * scripts/dso-ordering-test.py: New script.
>>
>>
next prev parent reply other threads:[~2019-11-25 9:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-20 17:51 Chung-Lin Tang
2019-07-23 13:21 ` Florian Weimer
2019-07-25 18:46 ` Chung-Lin Tang
2019-07-29 9:48 ` Florian Weimer
2019-08-05 10:39 ` Chung-Lin Tang
2019-08-05 10:45 ` Florian Weimer
2019-08-10 11:49 ` Chung-Lin Tang
2019-09-17 9:55 ` Ping " Chung-Lin Tang
2019-10-08 6:22 ` Ping x2 " Chung-Lin Tang
2019-10-08 17:41 ` Adhemerval Zanella
2019-10-31 13:13 ` Carlos O'Donell
2019-11-14 9:58 ` Chung-Lin Tang
2019-11-25 9:19 ` Chung-Lin Tang [this message]
2019-11-25 19:08 ` Carlos O'Donell
2019-11-26 8:19 ` Chung-Lin Tang
2019-11-27 15:20 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d9f8b04-3133-0e4f-c8a8-ff202db1339c@mentor.com \
--to=chunglin_tang@mentor.com \
--cc=carlos@redhat.com \
--cc=cltang@codesourcery.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).