The section headers present in the vdso mapped by the kernel seems to be corrupted, I dumped the vdso to a file and tried to analyse it using readelf and found this ->

$ readelf --sections ../llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/inferior-assert/vdso
There are 13 section headers, starting at offset 0x304:
readelf: Error: Reading 0x76 bytes extends past end of file for string table

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] HASH 000000b4 0000b4 000038 04 A 2 0 4
[ 2] DYNSYM 000000ec 0000ec 000090 10 A 3 1 4
[ 3] STRTAB 0000017c 00017c 000095 00 A 0 0 1
[ 4] VERSYM 00000212 000212 000012 02 A 2 0 2
[ 5] VERDEF 00000224 000224 000054 00 A 3 3 4
[ 6] DYNAMIC 00000278 000278 000080 08 WA 3 0 4
[ 7] PROGBITS 000002f8 0002f8 000214 04 WA 0 0 4
[ 8] STRTAB 00000520 000520 000076 00 A 0 0 32
[ 9] NOTE 00000598 000598 000060 00 A 0 0 4
[10] PROGBITS 000005f8 0005f8 000024 00 A 0 0 4
[11] PROGBITS 0000061c 00061c 000108 00 A 0 0 4
[12] PROGBITS 00000730 000730 000654 00 AX 0 0 16
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
readelf: Error: no .dynamic section in the dynamic segment

which is why LLDB is not able to properly read the file.

• The vdso libraries on the GCE have a fake_shshtrtab section (see below section 8)
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .hash HASH 000000b4 0000b4 000038 04 A 2 0 4
[ 2] .dynsym DYNSYM 000000ec 0000ec 000090 10 A 3 1 4
[ 3] .dynstr STRTAB 0000017c 00017c 000095 00 A 0 0 1
[ 4] .gnu.version VERSYM 00000212 000212 000012 02 A 2 0 2
[ 5] .gnu.version_d VERDEF 00000224 000224 000054 00 A 3 3 4
[ 6] .dynamic DYNAMIC 00000278 000278 000080 08 WA 3 0 4
[ 7] .rodata PROGBITS 000002f8 0002f8 000214 04 WA 0 0 4
[ 8] .fake_shstrtab STRTAB 00000520 000520 000076 00 A 0 0 32
[ 9] .note NOTE 00000598 000598 000060 00 A 0 0 4
[10] .eh_frame_hdr PROGBITS 000005f8 0005f8 000024 00 A 0 0 4
[11] .eh_frame PROGBITS 0000061c 00061c 000108 00 A 0 0 4
[12] .text PROGBITS 00000730 000730 000654 00 AX 0 0 16
• Now the ELF Header is
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0xd70
Start of program headers: 52 (bytes into file)
Start of section headers: 772 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 4
Size of section headers: 40 (bytes)
Number of section headers: 13
Section header string table index: 8

So initially LLDB allocates Start of section header + Number of section headers x Size of section headers = 1292 bytes of data for the vdso but the fake_shstrtab section offset is not in the limit calculated by lldb. Whereas in my case the shstrtab section is not fake and is within the limits of the formula I specified. Although the shstrtab section is at the place where the table reports it, so I think the vdso file is ok but there is a problem with lldb for reading ELF files. This is the situation for both the instances u shared with me.