[LLVMdev] Status of YAML IO?

Shankar Easwaran shankare at codeaurora.org
Wed Oct 31 19:46:44 PDT 2012

Hi Nick,
>> The range of flags would be integers ranging from LOW_PROC .. HIGH_PROC.
>> The Generic flags would be within the range less than LOW_PROC  and greater HIGH_PROC. Any value within the range LOW_PROC .. HIGH_PROC is os/platform specific.
>> What I was thinking was there could be a uint32_t flags() in the definedAtom which returns the flags, and platforms can act accordingly on the meaning of the flags in their pieces of code.
>> What do you think ?
> You still have not given an example of what information is missing in the current Atom model that is driving the need for this.
> It sounds like your flags() returns a value - not a set of bits.  Which means it can only be used for one thing.  What if you need two or more kinds of information/attributes not in the Atom model?   I don't see why LOW_PROC, HIGH_PROC is needed.  If we decide there are new kinds of information/attributes that are general we would just define new methods on Atom, rather than define a value to be returned by flags().
There are two usecases that I can think of now :-

1) flags :- These are used to determine what the Atom contains in 
addition to the content, could be that the Atom has
     a) follow on reference
     b) atom is part of a group, where other atoms are part of

The flags could be used to determine if there is a follow up atom or if 
the atom is part of a group.
Both of them would be useful than iterating through the reference list 
and iterating it and figuring out if there is a follow on reference / 
atom being part of a group.

2) Atom specific content types

This is where the LOW_PROC, and HIGH_PROC comes in, there are content 
types which are architecture specific.

Currently there are many types defined within contentType which are 
operating system specific. As more environments start using lld, I feel 
that many architectures would want to add.

Example for GNU support would include

a) checksum
b) hash
c) gnu prelink library list

I believe both of them would be solvable, by using a 64bit unsigned 
integer, where in the lower half is used by content type and the upper 
is used by flags. I dont think we would need more than 32 flags anytime 
soon. But atleast there is a possibility of adding more flags.

I think flags should be supported only by lld Core.


Shankar Easwaran

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

More information about the llvm-dev mailing list