This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Update LTO plugin interface


>> The only aspect of link
>> order that isn't maintained is the physical order of the sections in
>> memory.
>
> That is exactly the problem my proposal tries to address.

Really? That's not at all what PR 12248 is about. The physical order
of the sections (meaning the order of contributions within each output
section) -- in the absence of any linker scripts -- should be
irrelevant. With linker scripts, or any other form of layout control,
the link order is decoupled from the layout anyway.

> __udivdi3 is just an example. ?It can also happen to memcpy, or
> any library calls generated by GCC. I am enclosing a testcase for memcpy.

Regardless, if the compiler backend introduces a call to a runtime
support routine, it's expecting to bind to a specific routine in its
runtime support library. Anything else is unsupported. For gcc or
libgcc hackers, if you *really* need the interposed routine, it's
simple enough to link the .o instead of the .a, or use
--whole-archive.

Think about it -- any failure to bind to an interposed copy of memcpy
(or any other library call generated by gcc) is indistinguishable from
the compiler choosing to generate the code inline.

-cary


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]