[LLVMdev] [lld] filename in the atom model.

[Rui Ueyama]

On Mon, Dec 1, 2014 at 1:09 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:

> Hi,
>
> Since all the atoms in a file share the same filename/membername(for
> archives), we could have a field thats could be used as metadata. Formats
> may decide to store metadata information, if they decide to.
>
> We should restrict the types of metadata information that can be added
> though (metadataKinds).


Yes and no. We cannot just say we should restrict. What we need is to think
carefully before adding a field of Atom. If there's a legitimate reason,
it's totally okay to add a new one. What's worse is to invent a complicated
workaround just to avoid adding a new field.


>
> Shankar Easwaran
>
>
> On 12/1/2014 2:49 PM, Rui Ueyama wrote:
>
>> We don't need a filename for the PE/COFF writer, but if it existed, it
>> wouldn't hurt us. We'll leave the field nullptr.
>>
>> I don't think we need to vote here. Even if only one arch needs it, if it
>> should naturally be added to Atom, it should be added to Atom.
>>
>> On Mon, Dec 1, 2014 at 12:44 PM, Shankar Easwaran <
>> shankare at codeaurora.org>
>> wrote:
>>
>>  + Nick
>>>
>>> Rui,
>>>
>>> Does PECOFF writer need the filename in the writer as well, I am not sure
>>> if linker scripts are supported with PECOFF though.
>>>
>>> If PECOFF also needs it, I think it makes sense to store the filename in
>>> the Atom as the native format needs to store that information.
>>>
>>> The only option for the ELF writer to know this information is to use
>>> References if other flavors dont need the filename (only in DEBUG mode,
>>> clumsy but would work).
>>>
>>> PS : Moving this discussion to llvmdev.
>>>
>>> Shankar Easwaran
>>>
>>> On 12/1/2014 2:34 PM, Rui Ueyama wrote:
>>>
>>>  That sounds like we really need a new property of Atom.
>>>>
>>>> 1. If we run LLD in Release build, the roundtrip passes don't run, so
>>>> everything works fine.
>>>> 2. If we run LLD in Debug build (and from the unit tests), the
>>>> information
>>>> is dropped during the round-trip conversion, and it fails.
>>>> 3. RoundTrip tests should't drop any information.
>>>>
>>>> 2 and 3 conflicts.
>>>>
>>>> I should note that, again, I don't actually like the idea of YAML/Native
>>>> format, though. It feels like it doesn't worth the cost of maintaining
>>>> two
>>>> more different outputs.
>>>>
>>>> On Mon, Dec 1, 2014 at 12:20 PM, Shankar Easwaran <
>>>> shankare at codeaurora.org>
>>>> wrote:
>>>>
>>>>   Hi Rui,
>>>>
>>>>> We discussed to add a new property to the atom, but its really not
>>>>> needed
>>>>> as the original filename from where the atom was parsed is available in
>>>>> release mode(roundtrip passes dont get called in release mode).
>>>>>
>>>>> The discussion was here, http://lists.cs.uiuc.edu/
>>>>> pipermail/llvmdev/2014-
>>>>> November/078910.html.
>>>>>
>>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141201/2e2d6e5b/attachment.html>