search for: defaultlayout

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. > > DefaultLayout i...

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

...ions to the ".rela" sections only. Mips requires to use the "rel" format. So we need to be able to select format and names of relocation section, names of symbols like __rela_iplt_* / __rel_iplt_*, dynamic table tag DT_RELA / DT_REL. My current idea: - Add two virtual functions DefaultLayout::createDynamicRelocationTable() and DefaultLayout::getPLTRelocationTable(). Call these functions when we need to create relocation tables. By default these function create .rela.* sections. - Override createDynamicRelocationTable() and getPLTRelocationTable() in the MipsTargetLayout to create .rel....

...is required for now is to be able to assign a fixed address to a few atoms (the ones that will hold the reset & interrupt vectors) and place code/data sections in code/data memory (so we can simulate generated code and fix and optimize our LLVM target). I guess that can be done by adapting the DefaultLayout code in our own Layout class, but any hint or documentation about how to do this in a clean manner is welcome. I have another question: are there any plans concerning debug information ? In v3.4, the documentation says lld does not support DWARF info, although there are debug-related sections in l...

...? >> > There is a way that we can handle this without lot of tweaks. > > a) Assign the debug sections part of a linker internal segment(the segment > would not appear in the output file), hasOutputSegment will return true for > a debug section. > > b) Around lines 623, in DefaultLayout, we find out if the section is > associated with the special debug section, we add this sepecial segment to > the list of segments > The problem with this is that it's not just debug. We need to properly implement ELF semantics (ok, really gnu-ld semantics and the ELF spec doesn't...

Hi, We are currently developing an LLVM-based compilation toolchain for a micro-controller, but would need some advice about whether we should use lld as linker. So far we managed to write a basic target handler to read ELF files generated by llc and link them (and relocations seem to be applied correctly). But we have target-specific requirements: - the program will be loaded into memory as-is,

...; > Any ideas for the proper fix here? There is a way that we can handle this without lot of tweaks. a) Assign the debug sections part of a linker internal segment(the segment would not appear in the output file), hasOutputSegment will return true for a debug section. b) Around lines 623, in DefaultLayout, we find out if the section is associated with the special debug section, we add this sepecial segment to the list of segments c) Around lines 731 in DefaultLayout.h, we compare the segment type against the linker internal segment types, and assign offsets for the debug section. Lets not set t...

...ons only. Mips requires > to use the "rel" format. So we need to be able to select format and > names of relocation section, names of symbols like __rela_iplt_* / > __rel_iplt_*, dynamic table tag DT_RELA / DT_REL. > > My current idea: > - Add two virtual functions > DefaultLayout::createDynamicRelocationTable() and > DefaultLayout::getPLTRelocationTable(). Call these functions when we > need to create relocation tables. By default these function create > .rela.* sections. > - Override createDynamicRelocationTable() and getPLTRelocationTable() > in the MipsTar...

Debug info linking is currently broken due to how we handle reading and laying out non SHF_ALLOC sections. I posted a patch that partially fixes this, but it's both the wrong approach and doesn't handle multiple input files with debug info (wrong relocation values). The first issue is representing non SHF_ALLOC atoms in the Atom model. We currently don't have a type for this, and

...gt; </Include> <Include> <Filename>gnome-volume-control.desktop</Filename> </Include> <Include> <Filename>vumeter.desktop</Filename> </Include> </Menu> <Menu> <Name>wine-wine</Name> </Menu> <DefaultLayout inline="false"/> <Menu> <Name>alacarte-made</Name> <Directory>alacarte-made.directory</Directory> <Deleted/> </Menu> <Layout> <Merge type="menus"/> <Menuname>Accessories</Menuname> <Menuname&g...