assigned to @int3

Seems like fixing the function size calculation didn't address this problem. I will investigate this soonish.

Subscribing Greg Clayton in case he has ideas.

So LLDB, when parsing a symbol table, will look for N_SO symbols and it tries to match up a N_SO symbol with a name (source path) to the N_SO symbol without a name.

So for this binary:

$ dsymutil -s a.out

Symbol table for: 'a.out' (x86_64)

Index n_strx n_type n_sect n_desc n_value
======== -------- ------------------ ------ ------ ----------------
[ 0] 00000035 0e ( SECT ) 08 0000 0000000100008008 '__dyld_private'
[ 1] 00000044 64 (N_SO ) 00 0000 0000000000000000 '/Users/gclayton/Documents/src/args/'
[ 2] 00000068 64 (N_SO ) 00 0000 0000000000000000 'main.cpp'
[ 3] 00000071 66 (N_OSO ) 03 0001 0000000060664660 '/Users/gclayton/Documents/src/args/main.o'
[ 4] 00000001 2e (N_BNSYM ) 01 0000 0000000100003ef0
[ 5] 0000009b 24 (N_FUN ) 01 0000 0000000100003ef0 '_main'
[ 6] 00000001 24 (N_FUN ) 00 0000 0000000000000084
[ 7] 00000001 4e (N_ENSYM ) 01 0000 0000000000000084
[ 8] 00000001 64 (N_SO ) 01 0000 0000000000000000
[ 9] 00000002 0f ( SECT EXT) 01 0010 0000000100000000 '__mh_execute_header'
[ 10] 0000001 0f ( SECT EXT) 01 0000 0000000100003ef0 '_main'
[ 11] 0000001c 01 ( UNDF EXT) 00 0200 0000000000000000 '_printf'
[ 12] 00000024 01 ( UNDF EXT) 00 0200 0000000000000000 'dyld_stub_binder'

LLDB will simplify the symbol table like so:

(lldb) image dump symtab a.out
Symtab, file = /Users/gclayton/Documents/src/args/a.out, num_symbols = 7:
Debug symbol
|Synthetic symbol
||Externally Visible
|||
Index UserID DSX Type File Address/Value Load Address Size Flags Name

[ 0] 1 D SourceFile 0x0000000000000000 Sibling -> [ 3] 0x00640000 /Users/gclayton/Documents/src/args/main.cpp
[ 1] 3 D ObjectFile 0x0000000060664660 0x0000000000000000 0x00660001 /Users/gclayton/Documents/src/args/main.o
[ 2] 5 D X Code 0x0000000100003ef0 0x0000000000000084 0x000f0000 main
[ 3] 0 Data 0x0000000100008008 0x0000000000000008 0x000e0000 _dyld_private
[ 4] 9 X Data 0x0000000100000000 0x0000000000003ef0 0x000f0010 _mh_execute_header
[ 5] 11 Trampoline 0x0000000100003f74 0x0000000000000006 0x00010200 printf
[ 6] 12 X Undefined 0x0000000000000000 0x0000000000000000 0x00010200 dyld_stub_binder

Note that the UserID column refers to the original symbol index. Since the mach-o symbol table has so many duplicate symbol entries for something (like '_main' is described by symbols 5, 6 and 10, but LLDB will make only a single symbol for it in the symbol table that LLDB uses.

We see that the first symbol represents the N_SO:
[ 0] 1 D SourceFile 0x0000000000000000 Sibling -> [ 3] 0x00640000 /Users/gclayton/Documents/src/args/main.cpp

It points to a sibling symbol (as we see from "Sibling -> [ 3]"), or the first symbol that doesn't belong to the N_SO. This lets us simplify the symbol table that LLDB uses, but it still maintains the original scoping where all symbols from the first N_SO with a path and the last N_SO with no name create a scope where everything inside belongs to the source file.

So a few things could cause this:

• you have a N_SO in your execute with a name that isn't followed by a N_SO with no name (LLD bug)
• you have have a valid N_SO in your executable with a name and you have a N_SO with no name, but it is the last symbol in the symbol table (LLDB bug) and LLDB is complaining. The error message points to the N_SO with a UID of 145239, so that means if you dump the symbol table of the binary that causes this error, using "dsymutil -s /path/to/binary", then look for the symbol with index 145239, that should point you to the N_SO symbol that doesn't have a N_SO symbol after it with no name, or it might be that the N_SO symbol is the last symbol in the symbol table (this would be very rare as all local symbols usually come first in the mach-o symbol table, followed by exported symbols and then by undefined symbols

Ohhh. Our intended N_SOs with no name had a string index of zero, but because of D89639, it meant that they were pointing to a string with a single space, rather than an empty string. This was not at all obvious with llvm-nm because it doesn't quote strings, so a single space is indistinguishable from the empty string. But it's a lot more obvious with dsymutil -s since that does quote its strings.

Thanks Greg!!

The reason I originally wrote "dsymutil -s" in the first dsymutil was so I could see exactly what was in the mach-o symbol table and the quotes helped way back when. Glad you figured it out from my explanation!

mentioned in issue #48803