llvm dev - Dec 2017 - [LLD] Slow callstacks in gdb

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 should fix this.

Cheers,
Rafael

On Tue, Dec 5, 2017 at 1:22 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:
> 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171205/6b884263/attachment.html>

Rui Ueyama <ruiu at google.com> writes:
> On Tue, Dec 5, 2017 at 1:22 PM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
>
>> 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 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
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 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.

Cheers,
Rafael