Linear sweep creates functions starting in nop padding

[bdash]

Version and Platform (required):

• Binary Ninja Version: 5.4.9564-dev Ultimate, 76df23aa
• OS: macos
• OS Version: 26.4.1
• CPU Architecture: arm64

Bug Description:
When analyzing an aarch64 Linux binary (royal loop connects watchfully), I see that the nops inserted as padding between functions are often included as part of the following function.

In some cases it ends up creating a separate function that just falls through to the real function:

0094f15c    uint64_t sub_94f15c(void* arg1)

0094f15c     0  1f2003d5   nop       {sub_94f160}
{ Falls through into sub_94f160 }


0094f160    uint64_t sub_94f160(void* arg1)

0094f160     0* f353bda9   stp     x19, x20, [sp, #-0x30]! {__saved_x19} {__saved_x20}
0094f164    30  f30300aa   mov     x19, x0

This is mostly just noise, and doesn't seem to cause any real problems.

However, in some cases the function is only created at the nop:

00c49bdc    int64_t sub_c49bdc()

00c49bdc     0  1f2003d5   nop     
00c49be0     0  20d801d0   adrp    x0, 0x474f000
00c49be4     0  006440f9   ldr     x0, [x0, #0xc8]  {data_474f0c8}  {data_48b29f0}
00c49be8     0  000040f9   ldr     x0, [x0]  {data_48b29f0}
00c49bec     0  038840f9   ldr     x3, [x0, #0x110]
00c49bf0     0  00104279   ldrh    w0, [x0, #0x108]

There are no cross references to 0x00c49bdc, but there is a cross-reference to 0x00c49be0 where its address is passed to another function:

00c49f04                int16_t* x0_27 = sub_b5df40(sub_c49bdc+4, 0)

The incorrect function start makes cross-references much less useful as clicking on the function declaration shows no cross-references.

The function being created only at the nop address seems to happen when the only reference to the function is as a function pointer passed to another function (many of the functions passed to pthread_create and sub_b5df40 in this binary show this problem).

A fall-through function being created at the nop address seems to happen when there's a reference to the correct function start from a data variable, such as a C++ vtable. If you look at the vtable at 0x046b4dc0, you'll see that every function that has nop padding before it has a fall-through function in it.

Steps To Reproduce:
Open royal loop connects watchfully, wait for analysis to complete (it's not quick), and then look at some of the addresses mentioned above.

Workaround:
There's a manual workaround of using p to create a function at the correct start address then u to undefine the bogus function, but that's not practical. A similar workaround can be scripted, but that shouldn't be necessary. Both options tend to blow up the undo history as well.