The Fedora problem has been fixed by D63540.
But as reported by @omjavaid it regressed arm32: Ubuntu Xenial, Bionic and Debian Buster
I found it also reproducible with on Fedora in chroot with ubuntu-18.04-server-cloudimg-armhf.
The regression is due to:
GetAddressClass fails to recognized 0x102f0 as a code address:
PASS: (lldb) p (void)sync() GetAddressClass:0x102f1 GetAddressClass:0x102f1=(null) ValueIsAddress=1 section_type=1 GetAddressClass:0x96040 GetAddressClass:0x96040=__mmap ValueIsAddress=1 section_type=1 GetAddressClass:0x102f1 GetAddressClass:0x102f1=(null) ValueIsAddress=1 section_type=1 GetAddressClass:0x102f0 GetAddressClass:0x102f0=(null) ValueIsAddress=1 section_type=1 ... FAIL: (lldb) p (void)sync() GetAddressClass:0x102f1 GetAddressClass:0x102f1=_start ValueIsAddress=1 section_type=1 GetAddressClass:0x96040 GetAddressClass:0x96040=__mmap ValueIsAddress=1 section_type=1 GetAddressClass:0x102f1 GetAddressClass:0x102f1=_start ValueIsAddress=1 section_type=1 GetAddressClass:0x102f0 ...
That is due to:
symtab.fail:[ 11] 12 Invalid 0x00000000000102f0 0x0000000000000000 0x00000003 symtab.fail:[ 66] 99 X Code 0x00000000000102f0 0x0000000000000030 0x00000012 _start symtab.pass:[ 11] 12 Invalid 0x00000000000102f0 0x0000000000000030 0x00000003 symtab.pass:[ 66] 99 X Code 0x00000000000102f0 0x0000000000000030 0x00000012 _start
The difference is in the 'Invalid' symbol which is:
Num: Value Size Type Bind Vis Ndx Name 12: 000102f0 0 SECTION LOCAL DEFAULT 12
Apparently ARM32 relies on that section symbol to have proper size. I do not see how Symtab::InitAddressIndexes could handle STT_SECTION in a special way as that is ELF-type specific Symbol characteristics:
uint32_t m_flags; // A copy of the flags from the original symbol table, the // ObjectFile plug-in can interpret these
So if we have N symbols for address 0x1000 with size of zero and we have one with a valid size, do we leave all symbols with zero size stay with a size of zero? I was confused by the comment and wanted to clarify.