search for: targetlayout

Good point. But I suggest to do that by two steps. First, remove TargetLayout and rename DefaultLayout to TargetLayout. Second, merge TargetLayout and Layout. The first step is easy, the second step generates large diff, requires reviewing etc. On Fri, Apr 3, 2015 at 10:40 PM, Rui Ueyama <ruiu at google.com> wrote: > I'm wondering if we even need TargetLayout....

Hi Rui, Shankar, Do we really need empty TargetLayout class? No we have the following hierarchy: Layout <- DefaultLayout<> <- TargetLayout<> <- xxxTargetLayout<> I suggest to remove TargetLayout and rename DefaultLayout to TargetLayout. Thoughts? -- Simon Atanasyan

...ar apart from each > other into two different segments. Since it puts these two sections (.text > and .data) in the same ELF segment, the segment is forced to be huge > because the start addresses of these sections are far apart from each > other. I would begin by investigating how > TargetLayout<ELFT>::assignSectionsToSegments() works and go from there. > This function lives at lld/lib/ReaderWriter/ELF/TargetLayout.cpp. I don't > believe you can try any other flags to try to get this done without fixing > this logic. > > Rafael Auler > > On Wed, Jul 1, 2015 a...

Hi All, Congratulations on the major progress on the llvm linker lld over the past year including the new linker script support. This really makes it possible to ditch binutils altogether. It looks like lld's MEMORY sections are currently parsed but not evaluated, but so far that hasn't been a problem. The only snag is I can't figure out how to define the start of the .data section

Hi, Thanks a lot for your answer. It seems lld is still the best solution, even if it does not work "right out of the box" for us today. We already have a solution for the "objcopy" part (added the required output format to llvm-objdump). The ScriptLayout class seems to be empty for now (on the master branch at least), but we do not need linker scripts today. All that is