[lld] r223330 - Rewrite InputGraph's Group
Shankar Easwaran
shankare at codeaurora.org
Mon Dec 8 08:33:25 PST 2014
On 12/7/2014 7:19 PM, Rui Ueyama wrote:
> On Fri, Dec 5, 2014 at 9:13 AM, Shankar Easwaran <shankare at codeaurora.org>
> wrote:
>
>> Hi Rui,
>>
>> They key idea was to flatten the graph but also use tags to know about
>> some control flags, that change linker operation(group begins / ends (or)
>> what input files are part of as-needed).
I think you missed addressing this issue, the writer needs to know where
the group starts and where the group ends to print the Map file apppriately.
I would prefer to use tags, or could you let me know what would be the
alternative process other than going through the input elements twice.
>> The LinkingContext would need to know about what happens in the resolver
>> per input element (that would contain a tag and a file locator).
>>
>> These two requirements are really needed for the linker Gnu flavor for its
>> operation and the infrastructure needs to be scalable as well.
>>
> Yes, these are obvious needs. I have of course no intention to remove
> --as-needed from the linker.
>
> As you might have noticed, notifyProgress is not the only way that we can
> use for the core linker to the LinkingContext. It, for example, doesn't
> have to be real-time. Instead of telling the progress for each file, we
> could accumulate that information and pass it to the next pass.
>
While its possible in the current infrastructure to handle --as-needed,
I think we need to implement the necessary functions to call into the
linking context or to query the resolver as part of this patch(as a
replacement to notifyProgress).
Shankar Easwaran
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
More information about the llvm-commits
mailing list