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

[Rafael Avila de Espindola via llvm-dev]

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