search for: packed_endian_specific_integr

...rt::ulittle8_t StorageClass; support::ulittle8_t NumberOfAuxSymbols; }; and on PowerPC it generates errors like: /Users/jabbey/src/llvm/include/llvm/Support/Format.h: In member function 'int llvm::format_object1<T>::snprint(char*, unsigned int) const [with T = llvm::support::detail::packed_endian_specific_integral<unsigned int, little, unaligned>]': /Users/jabbey/src/llvm/tools/llvm-objdump/llvm-objdump.cpp:622: instantiated from here /Users/jabbey/src/llvm/include/llvm/Support/Format.h:88: warning: cannot pass objects of non-POD type 'const struct llvm::support::detail::packed_endian_speci...

...; >   support::ulittle8_t  NumberOfAuxSymbols; > }; > and on PowerPC it generates errors like: > /Users/jabbey/src/llvm/include/llvm/Support/Format.h: In member function > 'int llvm::format_object1<T>::snprint(char*, unsigned int) const [with T = > llvm::support::detail::packed_endian_specific_integral<unsigned int, little, > unaligned>]': > /Users/jabbey/src/llvm/tools/llvm-objdump/llvm-objdump.cpp:622: > instantiated from here > /Users/jabbey/src/llvm/include/llvm/Support/Format.h:88: warning: cannot > pass objects of non-POD type 'const struct > llvm::support:...

...pt finding buggy object files early? I mean, if an object > file is in an static archive, all "aligned" data in the object file might > not be aligned against the beginning of the archive file. It will at least be aligned to two bytes. With most current host architectures handling packed_endian_specific_integral is fairly efficient. For example, on x86_64 reading 32 bits with 1 2 and 4 byte alignment produces in all cases: movl (%rdi), %eax But on armv6 the aligned case is ldr r0, [r0] the 2 byte aligned case is ldrh r1, [r0, #2] ldrh r0, [r0] orr r0, r0, r1, lsl #16 and...

Rafael Avila de Espindola <rafael.espindola at gmail.com> writes: >> On Mar 22, 2014, at 1:31, Justin Bogner <mail at justinbogner.com> wrote: >> Also, the header includes a "clang::io" namespace with some operations >> for reading and writing little endian files. Should these be directly >> renamed to "llvm::io", or would something like

Martin Richtarsky <s at martinien.de> writes: > Output looks as follows [1] Seems sh_offset is missing? That is what readelf prints as Off > [17] .rela.text RELA 0000000000000000 071423 001728 18 > 1 4 8 The offset of rela text should have been aligned, but it is not. Can you report a bug on icc? As a work around using the gnu assembler if possible

Fantastic! Thanks for all of the input! I'll be considering all of it going forward. The plan right now is just to worry about ELF executables and nothing else. I'm very sympathetic to the "llvm-objtool" change. If everyone is cool with it I'll change the name in the next CL to "llvm-objtool". To start out I implemented a very basic ELF64LE specific bit of code.

...nst unsigned char *&Data); >> >> The (aligned) ReadLE32 is easily represented by the stuff in Endian.h, >> but the write to an ostream and reading unaligned aren't addressed very >> well at present. > > ulittle32 is actually unaligned: > > typedef detail::packed_endian_specific_integral > <uint32_t, little, unaligned> ulittle32_t > > But yes, I don't think we have anything for writing and I it is > probably not trivial to extend it. We can probably add the existing > write functions to Endian.h itself. A bit more detail on this. For r...