[musl] questions on src/ldso/aarch64/dlsym.s

[musl] questions on src/ldso/aarch64/dlsym.s

[Bill Roberts]

Howdy folks,

I was hoping you could shed some light on src/ldso/aarch64/dlsym.s? As 
it's not apparent to me how this stub gets executed. I have tried a few 
things to no avail. I don't get how there is C symbols defined with the 
same name and then these defined in asm, what am I missing, it seems 
obvious...

```asm
.global dlsym
.hidden __dlsym
.type dlsym,%function
dlsym:
         mov x2,x30
         b __dlsym
```

Thanks,
Bill

Re: [musl] questions on src/ldso/aarch64/dlsym.s

[Rich Felker]

On Thu, Nov 20, 2025 at 08:49:07PM -0600, Bill Roberts wrote:
> Howdy folks,
> 
> I was hoping you could shed some light on src/ldso/aarch64/dlsym.s? As it's
> not apparent to me how this stub gets executed. I have tried a few things to
> no avail. I don't get how there is C symbols defined with the same name and
> then these defined in asm, what am I missing, it seems obvious...
> 
> ```asm
> .global dlsym
> .hidden __dlsym
> .type dlsym,%function
> dlsym:
>         mov x2,x30
>         b __dlsym
> ```
> 
> Thanks,
> Bill

In the make rules, presence of src/xxx/$ARCH/yyy.[csS] files replaces
the corresponding src/xxx/yyy.c file and prevents the latter from
being built at all. The above isn't a stub, it's the definition for
the public dlsym symbol, and it calls the hidden __dlsym symbol.

__dlsym in turn has an always-failing weak definition in
src/ldso/__dlsym.c that's superseded by the actually-functional
definition of __dlsym in ldso/dynlink.c for dynamic libc.

Rich

Re: [musl] questions on src/ldso/aarch64/dlsym.s

[Bill Roberts]

On 11/20/25 9:00 PM, Rich Felker wrote:
> On Thu, Nov 20, 2025 at 08:49:07PM -0600, Bill Roberts wrote:
>> Howdy folks,
>>
>> I was hoping you could shed some light on src/ldso/aarch64/dlsym.s? As it's
>> not apparent to me how this stub gets executed. I have tried a few things to
>> no avail. I don't get how there is C symbols defined with the same name and
>> then these defined in asm, what am I missing, it seems obvious...
>>
>> ```asm
>> .global dlsym
>> .hidden __dlsym
>> .type dlsym,%function
>> dlsym:
>>          mov x2,x30
>>          b __dlsym
>> ```
>>
>> Thanks,
>> Bill
> 
> In the make rules, presence of src/xxx/$ARCH/yyy.[csS] files replaces
> the corresponding src/xxx/yyy.c file and prevents the latter from
> being built at all. The above isn't a stub, it's the definition for
> the public dlsym symbol, and it calls the hidden __dlsym symbol.
> 
> __dlsym in turn has an always-failing weak definition in
> src/ldso/__dlsym.c that's superseded by the actually-functional
> definition of __dlsym in ldso/dynlink.c for dynamic libc.
> 
> Rich

Thanks, Rich, that makes a lot more sense now. So is there a huge 
benefit in using the generic c implementation (I'm assuming its a 
generic implementation) versus an arch specific stub?

I ask this on the crusade to ditching .s and .S for .c and inline 
assembly. So when I went to a .c file, it was clashing from the 
aforementioned Make logic. Perhaps this is better just in a .S (capital) 
file, then we can use an ifdef on bti c, or perhaps as Szabolcs 
mentioned in the past, just leave the bti c in there unconditionally as 
its backwards compat?

Bill

Re: [musl] questions on src/ldso/aarch64/dlsym.s

[Rich Felker]

On Thu, Nov 20, 2025 at 09:08:40PM -0600, Bill Roberts wrote:
> 
> 
> On 11/20/25 9:00 PM, Rich Felker wrote:
> > On Thu, Nov 20, 2025 at 08:49:07PM -0600, Bill Roberts wrote:
> > > Howdy folks,
> > > 
> > > I was hoping you could shed some light on src/ldso/aarch64/dlsym.s? As it's
> > > not apparent to me how this stub gets executed. I have tried a few things to
> > > no avail. I don't get how there is C symbols defined with the same name and
> > > then these defined in asm, what am I missing, it seems obvious...
> > > 
> > > ```asm
> > > .global dlsym
> > > .hidden __dlsym
> > > .type dlsym,%function
> > > dlsym:
> > >          mov x2,x30
> > >          b __dlsym
> > > ```
> > > 
> > > Thanks,
> > > Bill
> > 
> > In the make rules, presence of src/xxx/$ARCH/yyy.[csS] files replaces
> > the corresponding src/xxx/yyy.c file and prevents the latter from
> > being built at all. The above isn't a stub, it's the definition for
> > the public dlsym symbol, and it calls the hidden __dlsym symbol.
> > 
> > __dlsym in turn has an always-failing weak definition in
> > src/ldso/__dlsym.c that's superseded by the actually-functional
> > definition of __dlsym in ldso/dynlink.c for dynamic libc.
> > 
> > Rich
> 
> Thanks, Rich, that makes a lot more sense now. So is there a huge benefit in
> using the generic c implementation (I'm assuming its a generic
> implementation) versus an arch specific stub?
> 
> I ask this on the crusade to ditching .s and .S for .c and inline assembly.
> So when I went to a .c file, it was clashing from the aforementioned Make
> logic. Perhaps this is better just in a .S (capital) file, then we can use
> an ifdef on bti c, or perhaps as Szabolcs mentioned in the past, just leave
> the bti c in there unconditionally as its backwards compat?

This is one of the places the asm entry point is essential, because it
needs to be able to convert its own return address to a third argument
to the internal __dlsym in order for RTLD_NEXT to work.

Rich