svn commit: r368789 - head/libexec/rtld-elf/rtld-libc
John Baldwin
jhb at FreeBSD.org
Mon Dec 21 17:31:09 UTC 2020
On 12/19/20 8:27 PM, Ryan Libby wrote:
> On Sat, Dec 19, 2020 at 7:23 PM John Baldwin <jhb at freebsd.org> wrote:
>>
>> On 12/19/20 12:38 AM, Ryan Libby wrote:
>>> Author: rlibby
>>> Date: Sat Dec 19 08:38:31 2020
>>> New Revision: 368789
>>> URL: https://svnweb.freebsd.org/changeset/base/368789
>>>
>>> Log:
>>> rtld-elf: link udivmoddi4 from compiler_rt
>>>
>>> This fixes the gcc9 build of rtld-elf32 on amd64, which needed an
>>> implementation of udivmoddi4.
>>>
>>> rtld-elf uses certain functions normally found in libc, and so it
>>> includes certain files from libc in its own build. It has two
>>> mechanisms to include files from libc: one that rebuilds source files in
>>> the rtld-elf environment, and one that extracts object files from a
>>> purpose-built no-SSP PIC archive.
>>>
>>> In addition to libc functions, rtld-elf may need to link functions
>>> normally found in libcompiler_rt (formerly libgcc). Now, add an ability
>>> to rebuild libcompiler_rt source files in the rtld-elf environment. We
>>> don't yet have a need for an object file extraction mechanism.
>>>
>>> libcompiler_rt could also supply udivdi3 and umoddi3, but leave them
>>> alone for now.
>>>
>>> Reviewed by: arichardson, kib
>>> Sponsored by: Dell EMC Isilon
>>> Differential Revision: https://reviews.freebsd.org/D27665
>>
>> Hmm, I had just linked against libcompiler_rt directly as we do on arm:
>>
>> https://reviews.freebsd.org/D26199
>>
>> It was stuck waiting for review feedback.
>>
>> Given libcompiler_rt is a static archive, we could probably safely link
>> against it directly unlike libc where we have to pick specific object
>> files.
>>
>> --
>> John Baldwin
>
> Sorry, I wasn't aware of your review. Do you want this backed out?
No. I do have other patches you can see in that review stack that might
be relevant for GCC 9. Some of them I should push as they've been
reviewed, but not all of them are ok'd I think.
> I did see the arm path. I think it is not quite right, because
> libcompiler_rt is compiled with -fstack-protector-strong, which is not
> compatible with rtld. However, it will work in practice if stack
> protection doesn't actually get used on any linked function.
Hmm, ok. I think it's fine to use the current approach then, and perhaps
fix arm to match it and keep SSP out of rtld.
--
John Baldwin
More information about the svn-src-head
mailing list