[PATCH] Preliminary support for dynamically loadable coff objects

Andy Ayers andya at microsoft.com
Thu Feb 26 16:59:41 PST 2015


Still working on tests. The verify option to rtdyld turned up some things needing fixing, which is great (we didn't see these since we are strictly in-proc).

Working on a test also brought up some other issues, in part since we're really loading up a coff object file (not a PE):

- The way we use this code now we never see the REL32 relocations, but every test case I can create from text input creates these (and we really should too, we're just not doing it yet). So I'll add support for this class of relocs -- though maybe not testing for the full set of REL32_* variants yet. These relative relocations can only be used if the dynamic loader promises to keep sections within 32 bit reaches of each other. I currently don't see any way to ensure this will be true.

- ADDR32NB is a bit of a hack, since (from what I can tell) there is no real notion of an image base, at least in the non-PE case. I don't need this to work since I only see these relocs in .pdata which I am ignoring, but it would be nice if it there would be some way to have a base and they are used more broadly. For instance some times jump tables are encoded this way to save size.

- Zero sized sections cause trouble. I routinely see zero sized .data and .bss. I have marked any zero sized section as not required for execution and am deferring looking at section data in some places until we know the section is required. An alternative here would be to get the coff producer to stop emitting zero sized sections.

Hope to have an update out in a day or two, but I have some vacation here and there. So we'll see.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7793

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list