[PATCH] [Core] Add type and size to SharedLibraryAtom

[Shankar Kalpathi Easwaran]

================
Comment at: include/lld/Core/SharedLibraryAtom.h:26
@@ +25,3 @@
+  enum Type {
+    Unknown,
+    Function,
----------------
kledzik at apple.com wrote:
> Shankar Kalpathi Easwaran wrote:
> > I would prefer the Unknown to be removed and replaced by a llvm_unreachable when detecting the type.
> I don't think we want to assert whenever the linker sees a DSO with a symbol that is not STT_FUNC or STT_OBJECT.  We need to track that is it neither.  So, later if a R_X86_64_32S  is used, it will turn into a PLT (for code) or R_X86_64_COPY (for data) and a linker error for anything else.  But an "unknown" DSO symbol can be used with other kinds of relocations.
Ok.

================
Comment at: lib/ReaderWriter/Native/NativeFileFormat.h:175-179
@@ -174,5 +174,7 @@
 struct NativeSharedLibraryAtomIvarsV1 {
+  uint64_t  size;
   uint32_t  nameOffset;
   uint32_t  loadNameOffset;
+  uint32_t  type;
   uint32_t  flags;
 };
----------------
kledzik at apple.com wrote:
> Shankar Kalpathi Easwaran wrote:
> > was curious, if is this a coding convention of higher sizes ordered before low (uint64_t before uint32_t) ?
> Sorting fields biggest to smallest reduces the amount of implicit alignment padding the compiler might add.   That said, will R_X86_64_COPY even work with a size > 4GB?
That should work, but never been tested I think. If there is a code that tries to access a 4GB sized array outside the shared library, possibly a warning can be issued to compile the code with the PIC option.

On the same note, if we find that the shared library data is in .bss, we could generate a GLOB_DAT relocation instead, because anyways even if you copy the data at startup time, its going to be zeroed.  Not sure if this sort of optimization is done by other ELF linkers.


http://llvm-reviews.chandlerc.com/D1760