Rui Ueyama <firstname.lastname@example.org> writes:
Martin Richtarsky <email@example.com> writes:
> Output looks as follows  Seems sh_offset is missing?
That is what readelf prints as Off
>  .rela.text RELA 0000000000000000 071423 001728
> 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 should fix this.
Yeah this is a violation of the spec and must be a bug in ICC. That being
said, is there a practical benefit of checking the validity of the
alignment, except 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
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 the unaligned case is
ldrb r1, [r0]
ldrb r2, [r0, #1]
ldrb r3, [r0, #2]
ldrb r0, [r0, #3]
orr r1, r1, r2, lsl #8
orr r0, r3, r0, lsl #8
orr r0, r1, r0, lsl #16
On armv7 it is a single ldr on all cases.
Now, I don't really know how much we support *host* architectures
without a unaligned load instruction. If we don't care about making lld
and other llvm tools slower on those host architectures we could use
packed_endian_specific_integral with an alignment of 1 and remove the
check. I guess we have to ask on llvmdev before changing that.