SuperSize uses full_name to look up source paths. However, there are weird cases where two unrelated symbols with the same name, but in different sections can be mashed together, leading to bogus symbols.

An example for chrome_public_apk is the symbol with full_name 'clip1'. Both LLD and LLD-LTO exhibit this, but let's look at the *non-LTO LLD* build (since the .o files are ELF and easier to deal with). In SuperSize console:

>>> for s in [s for s in size_info.raw_symbols if s.name == 'clip1']: Print(s)
b@0x2f267a8  383 (size=766) third_party/libwebp/src/dsp/dec_clip_tables.c
    clip1 (num_aliases=2)
b@0x2f267a8  383 (size=766) third_party/libwebp/src/dsp/enc.c
    clip1 (num_aliases=2)

However, looking at the sources, we see:

********
enc.c: https://cs.corp.google.com/piper///depot/google3/third_party/libwebp/v0_2/src/dsp/enc.c?rcl=193265058&l=87

static uint8_t clip1[255 + 510 + 1];    // clips [-255,510] to [0,255]

********
dec_clip_tables.c: https://cs.corp.google.com/piper///depot/google3/third_party/libwebp/v0_2/src/dsp/dec_clip_tables.c?rcl=172184170&l=264

#if (USE_STATIC_TABLES == 1)
...
static const uint8_t clip1[255 + 511 + 1] = {
...
#else
...
static uint8_t clip1[255 + 511 + 1];
...
#endif


The two variables have sizes 766 and 767 respectively. So somehow the second one disappeared?

Let's look at the .map file (need to decompress lib.unstripped/libchrome.so.map.gz):
$ grep \\bclip1\\b --line-number libchrome.so.map
1720877: 304b11c  304b11c      2fe     1         obj/third_party/libwebp/libwebp_dsp.a(libwebp_dsp/enc.o):(.bss.clip1)
1720878: 304b11c  304b11c      2fe     1                 clip1

So only enc.o one made it to the ELF?

Let's run llvm-nm on the separate .o files (in /obj/third_party/libwebp/libwebp_dsp/):

$ nm enc.o | grep \\bclip1\\b
00000000 b clip1

$ nm dec_clip_tables.o | grep \\bclip1\\b
00000000 r clip1

So the 'clip1' symbol are in different sections (.bss and .rodata), and the second one was trimmed, and probably should be excluded. But it seems that when SuperSize runs nm on enc.o and dec_clip_tables.o, it stores

  {..., 'clip1': ['.../enc.o', '.../dec_clip_table.o'], ...}

which _AssignNmAliasPathsAndCreatePathAliases() used to duplicate 'clip1' found in the .map file!