Follow @Openwall on Twitter for new release announcements and other news
[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251121032922.GU1827@brightrain.aerifal.cx>
Date: Thu, 20 Nov 2025 22:29:22 -0500
From: Rich Felker <dalias@...c.org>
To: Bill Roberts <bill.roberts@...s.arm.com>
Cc: musl@...ts.openwall.com, Szabolcs Nagy <nsz@...t70.net>
Subject: Re: questions on src/ldso/aarch64/dlsym.s

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.