Re: [PATCH] malloc: Fix malloc debug for 2.35 onwards

[Stafford Horne <shorne@gmail.com>]

On Tue, Nov 16, 2021 at 10:45:17AM +0530, Siddhesh Poyarekar wrote:
> On 11/16/21 10:42, Stafford Horne wrote:
> > On Tue, Nov 16, 2021 at 04:17:10AM +0530, Siddhesh Poyarekar wrote:
> > > On 11/16/21 02:37, Stafford Horne wrote:
> > > > I am not sure, after my patch the SHLIB_COMPAT usage is just there for compat
> > > > symbols.  As you mention using SHLIB_COMPAT to ensure libc_malloc_debug.so and
> > > > libc.so have the same version seems strange, I would think that would be
> > > > controlled by shlib-version or done out of the box.
> > > 
> > > Right, so it mostly works, i.e. you have symbols with version names:
> > > 
> > > ...
> > > > 00009bb4 g    DF .text	00000030  GLIBC_2.35  memalign
> > > > 0000a5a8 g    DF .text	00000138  GLIBC_2.35  mallinfo
> > > > 000091a0 g    DF .text	00000180  GLIBC_2.35  malloc
> > > > 0000a2ac g    DF .text	000000f8  GLIBC_2.35  mallopt
> > > ...
> > > 
> > > but they're default versions, which is not desirable since we don't want
> > > this library to be linkable.  So you will need a new macro that always
> > > creates the non-default symbol at the version that it was introduced.
> > 
> > I think I get what you mean.  Is this something you are planning to sort out?
> > As is without this patch the mem tests are failing on my port, and any future
> > ports.  For existing ports it is working because of the HACK as you say.
> 
> I was hoping you'd do that ;)  If you're unable to, I'll try to get to it
> later in the week.

Sure :), Let me have a look at it.

Thanks,

-Stafford