search for: elfstream

...ity of the code generated. To double-check, I've disassembled over 5,000 unique object files and compared to GCC disassembly, and things are looking very good. My Mapping Symbols patch was key to ensuring minimal noise in that analysis. At this point, my biggest concern is the quality of the ElfStreamer, and I haven't done anything to verify the linker. But everything seems to "just work", so maybe time to go find bigger fish to fry? What do you think? Should we flip the switch? Thanks, Greg On Tue, Nov 20, 2012 at 1:06 AM, Renato Golin <rengolin at systemcall.org> wrot...

Hi Greg, > At this point, my biggest concern is the quality of the > ElfStreamer, and I haven't done anything to verify the linker. But > everything seems to "just work", so maybe time to go find bigger fish > to fry? What do you think? Should we flip the switch? I'd be in favour of it. All of the gaps I'm aware of (haphazard build attributes m...

Hi Rafael, Sure, the expansion of at least .cpload should be done in the Target ELFStreamer but AFAICS it doesn't solve my initial problem. MCCodeGenInfo is not created in tools where CodeGen isn't needed (llvm-mc) and it's still not possible to access the Relocation Model in MCObjectFileInfo from the target streamer (private member). Am I missing something obvious ? There...

...so much. The goal is GAS compatibility, right? Not UAL? Or is there a hope to make both work? Thanks, Greg On Tue, Nov 20, 2012 at 11:49 AM, Tim Northover <t.p.northover at gmail.com>wrote: > Hi Greg, > > > At this point, my biggest concern is the quality of the > > ElfStreamer, and I haven't done anything to verify the linker. But > > everything seems to "just work", so maybe time to go find bigger fish > > to fry? What do you think? Should we flip the switch? > > I'd be in favour of it. All of the gaps I'm aware of (haphazard...

On 20 November 2012 03:22, Greg Fitzgerald <garious at gmail.com> wrote: > I read through "ELF for the ARM Architecture" and my best guess has > been to inspect .ARM.attributes in the elf-dump's section data, but > both LLVM and GCC use "aeabi" for the vendor name. "aeabi" is the "pseudo-vendor" which is normally printed to the attributes

Is there a reliable way to unit-test that LLVM's integrated assembler was used? I read through "ELF for the ARM Architecture" and my best guess has been to inspect .ARM.attributes in the elf-dump's section data, but both LLVM and GCC use "aeabi" for the vendor name. I've found several ways to distinguish the two (such as a magic number where GCC uses ELFOSABI_SYSV

Some Mips macros (e.g. la[1]) and the handling of Mips directives used for Position-Independent Programming (e.g. .cpload[2]) require access to Reloc::Model from within the Assembly Parser but there doesn't seem to be a way to do it in its current form. 1) Reloc::Model is passed to MCObjectFileInfo but it's a private member of that class 2) TargetMachine is not accessible I can also