llvm dev - Aug 2013 - [LLVMdev] [lld] -emit-yaml doesnot contain linker added symbols specified with command line options

Hi Nick,

The problem is when the -emit-yaml option is used, the writer is set to 
the YAML writer.

The YAML writer doesnot have anything to add here.

The problem can be solved by having the YAML writer append a list of 
undefined atoms specified by the -u option, but the problem I have is 
each flavor has extra command line options
for which it wants to create a DefinedAtom/UndefinedAtom. The flavor 
also may want to add extra linker internal files in the future.

I prefer addImplicitFiles calling the reader to add more files, which 
means addFiles API moves to the reader.

Thanks

Shankar Easwaran


On 8/28/2013 4:57 PM, Nick Kledzik wrote:
> Shankar,
>
> The LinkingContext has a addImplictFiles() method that is supposed to call
the Writer and give it a chance to add any implicit files.  Is the problem that
the -u atoms are not attached to that implicit file?  Or that the implicit file
is not getting added?  Or that this got lost in the transition from InputFiles
to InputGraph?
>
> -Nick
>
> On Aug 28, 2013, at 2:44 PM, Shankar Easwaran <shankare at
codeaurora.org> wrote:
>> Right now, linker added symbols specified by the -u option do not endup
in the output YAML file.
>>
>> This is because the target specific Writers dont get called, which
creates the undefined atoms.
>>
>> I am in the process of adding more options and I would like the atoms
created internally by the options available in the output YAML file.
>>
>> The options that I am trying to consider for the linker internal atoms
to appear in the output YAML file are :-
>>
>> a) Replace Writer::addFiles to Reader::addFiles
>>
>> This would achieve any file to be added to the list of input files that
is processed.
>>
>>                               (or)
>> b) Create a seperate API in the inputGraph for the driver to add
lld::Files, that are consumed by the Universal driver and that gets
>> added to the list of File objects that is being considered
>>
>>                               (or)
>>
>> c) Handle all the command line switches of -u or any atoms that we want
to see them appear in the YAML file as a seperate pass.
>>
>> I dont like the option (c), because we are using a hammer to kill this
problem.
>>
>> Thanks
>>
>> Shankar Easwaran
>> -- 
>>
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation
>
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

On Aug 28, 2013, at 3:14 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:
> Hi Nick,
> 
> The problem is when the -emit-yaml option is used, the writer is set to the
YAML writer.
Ah!
> 
> The YAML writer does not have anything to add here.
> 
> The problem can be solved by having the YAML writer append a list of
undefined atoms specified by the -u option, but the problem I have is each
flavor has extra command line options
> for which it wants to create a DefinedAtom/UndefinedAtom. The flavor also
may want to add extra linker internal files in the future.
> 
> I prefer addImplicitFiles calling the reader to add more files, which means
addFiles API moves to the reader.
But won’t that fail too if you were using a YAML Reader and ELF Writer?  

Since we are talking about files/atoms that are created because of command line
options, perhaps the Driver should be creating the files/atoms.  In the case of
-u, it would be nice to group them all in one file named “command line option
-u” so that any error messages about undefined symbols says the references was
from “command line option -u”  (as opposed to the -u UndefinedAtoms come from a
generic internal file).  Also for the case of -u, the Driver can make generic
UndefinedAtoms.  Other options may need platform specific atoms which may be
created with the help of static Writer methods.

-Nick

> On 8/28/2013 4:57 PM, Nick Kledzik wrote:
>> Shankar,
>> 
>> The LinkingContext has a addImplictFiles() method that is supposed to
call the Writer and give it a chance to add any implicit files.  Is the problem
that the -u atoms are not attached to that implicit file?  Or that the implicit
file is not getting added?  Or that this got lost in the transition from
InputFiles to InputGraph?
>> 
>> -Nick
>> 
>> On Aug 28, 2013, at 2:44 PM, Shankar Easwaran <shankare at
codeaurora.org> wrote:
>>> Right now, linker added symbols specified by the -u option do not
endup in the output YAML file.
>>> 
>>> This is because the target specific Writers dont get called, which
creates the undefined atoms.
>>> 
>>> I am in the process of adding more options and I would like the
atoms created internally by the options available in the output YAML file.
>>> 
>>> The options that I am trying to consider for the linker internal
atoms to appear in the output YAML file are :-
>>> 
>>> a) Replace Writer::addFiles to Reader::addFiles
>>> 
>>> This would achieve any file to be added to the list of input files
that is processed.
>>> 
>>>                              (or)
>>> b) Create a seperate API in the inputGraph for the driver to add
lld::Files, that are consumed by the Universal driver and that gets
>>> added to the list of File objects that is being considered
>>> 
>>>                              (or)
>>> 
>>> c) Handle all the command line switches of -u or any atoms that we
want to see them appear in the YAML file as a seperate pass.
>>> 
>>> I dont like the option (c), because we are using a hammer to kill
this problem.
>>> 
>>> Thanks
>>> 
>>> Shankar Easwaran
>>> -- 
>>> 
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation
>> 
>> 
> 
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by the Linux Foundation

Hi Nick,
>> The YAML writer does not have anything to add here.
>>
>> The problem can be solved by having the YAML writer append a list of
undefined atoms specified by the -u option, but the problem I have is each
flavor has extra command line options
>> for which it wants to create a DefinedAtom/UndefinedAtom. The flavor
also may want to add extra linker internal files in the future.
>>
>> I prefer addImplicitFiles calling the reader to add more files, which
means addFiles API moves to the reader.
> But won’t that fail too if you were using a YAML Reader and ELF Writer?
Yeah :(
> Since we are talking about files/atoms that are created because of command
line options, perhaps the Driver should be creating the files/atoms.
Currently the Driver has a notion of all the files that it processes are 
all Linker Inputs. InputGraph could have an additional function, to just 
add to it a list of files created implicitly by the linker. The 
UniversalDriver can then look at this list and append the list of files 
to the vector of files and then process the InputFiles.
>   In the case of -u, it would be nice to group them all in one file named
“command line option -u” so that any error messages about undefined symbols says
the references was from “command line option -u”  (as opposed to the -u
UndefinedAtoms come from a generic internal file).
Agree.
>   Also for the case of -u, the Driver can make generic UndefinedAtoms.
ELF would want to treat the undefined symbols as a weak undefined 
symbols. So the driver cant create undefined atoms.

Below is an example :-

$cat 1.c
int _start() { return 0; }
$gcc -c 1.c
$ld -u myundef 1.o
==> Does not throw any error, the resolver was hinted that /myundef /was 
a undefined weak symbol.
>   Other options may need platform specific atoms which may be created with
the help of static Writer methods.
We wouldnt be able to override the functionality with each flavor, if we 
have a static method, or you had thought of something else ?

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130828/a5ae9afd/attachment.html>