This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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


>> I wouldn't expect the compiler to introduce a call to anything in libm
>> when -lm isn't already specified on the command line (that would break
>> even without LTO).
>
> Right--that would break without LTO, but it doesn't follow that we
> should make it work with LTO.

That's my point, too.

>> With what I'm suggesting, we'll only resolve libcalls to libraries
>> that were originally specified on the command line.
>
> OK. ?Another concern I have with this is that there is no canonical
> location across all systems for some of these functions. ?In general -lc
> and -lm will suffice, but on some specific systems they may not. ?And
> there are functions which are in libc on some systems and in libm on
> others, such as frexp. ?So if we have a mapping from function to
> library, I'm afraid we may get caught up in system dependencies which
> are really kind of irrelevant. ?What really matters, I think, is not the
> specific library per function; it's the set of libraries we need to
> rescan.

My suggestion was to have the plugin give the linker a list of
libcalls, and the linker would note where it found each symbol during
its normal library scanning. If we need one of those symbols later and
haven't already linked it in, we'll know where to go find it (we won't
even have to rescan the library). We don't need to have a canonical
list of libraries or locations -- we just go with what was given on
the command line.

>> Another way to do this would be to put a marker in the command line
>> that identifies where those libraries begin, and the linker could just
>> go back and rescan those libraries if needed, before the final layout
>> of the endcaps.
>
> I like that idea in general, but the difficulty is knowing where to put
> the marker. ?E.g., the user is going to specify -lm, and we are going to
> need to rescan it. ?If the user writes -lm -lmylib1 -lmylib2 we want to
> rescan -lm but we don't really need to rescan mylib1 and mylib2.

Right. The gcc driver would have to have some concept of which
libraries might contain libcalls, and add brackets around them on the
linker command line to mark them as runtime support libraries, whether
they're added by the driver itself, or passed on the gcc command line
by the user.

-cary


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