RE: ____wcstold_l_internal Question

[Samir Droubi <samirdr@mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 3617 bytes --]

<libc-help@sourceware.org> wrote:

> >

> > * Samir Droubi via Libc-help:

> >

> > > I was profiling a project that I have been working on and the function

> > > above shows up amongst other internal functions. I was wondering if

> > > you could shed a light on what could possibly be happening to cause

> > > calls to this function to be so frequent. Here is the profiling

> > > result:

> > >

> > >   13.72%  mitscriptbc  libc.so.6             [.] ____wcstold_l_internal

> > >    5.45%  mitscriptbc  libc.so.6             [.] ____wcstof_l_internal

> > >    2.46%  mitscriptbc  libc.so.6             [.] round_and_return

> > >    2.28%  mitscriptbc  libc.so.6             [.] ____wcstod_l_internal

> > >

> > > The libc version being used is 2.35.

> I've noticed on ubuntu 22.04 (2.35 as well) `__wcstold_l` is showing up

> in perf profiles incorrectly. It's usually malloc / memcpy / whatever other

> functions are usually hot if you look at the asm.


> Not sure where the bug is but don't think `__wcstold` is whats taking up

> all those cycles.


I have noticed the same thing. I started noticing this when I was profiling on ubuntu 22.04 (with libc 2.35).

When I look at the annotated assembly in perf for `____wcstold_l_internal`, I see that I am in `_int_free`, but I still see calls to  `____wcstold_l_internal`.

Specifically, here is a segment of what I am seeing:


```

       │      ./malloc/malloc.c:4605

  0.01 │        mov        0x8(%rbp),%rdx
  0.08 │        and        $0xfffffffffffffff8,%rdx
  1.36 │        cmp        %rax,%rdx
       │      ↓ jne        716
       │      ./malloc/malloc.c:4607
  0.14 │        mov        %rbp,%rdi
       │      → call       ____wcstod_l_internal
       │      ./malloc/malloc.c:4610
  1.39 │  b9:   cmp        %r14,0x60(%r12)
  0.01 │      ↓ je         480
       │      ./malloc/malloc.c:4615
  0.05 │     ┌──testb      $0x1,0x8(%r14,%r15,1)
  9.31 │     ├──je         520
       │     │./malloc/malloc.c:4619
  1.31 │     │  andq       $0xfffffffffffffffe,0x8(%r14)

```


I was also confused about why `wcstold_l` would be called here, at least from a quick glance at the external function definition.

Is there a way to confirm that this is actually a problem with perf? When I was looking at what ./malloc/malloc.c:4607 is I found this:

https://github.com/bminor/glibc/blob/release/2.35/master/malloc/malloc.c#L4607

Which calls this macro: https://github.com/bminor/glibc/blob/release/2.35/master/malloc/malloc.c#L1436

which is reading this field: https://github.com/bminor/glibc/blob/release/2.35/master/malloc/malloc.c#L1151

Reading the comments in the file it seems that INTERNAL_SIZE_T  should be defined as size_t: https://github.com/bminor/glibc/blob/release/2.35/master/malloc/malloc.c#L173

I don't really see why those calls to `____wcstold_l_internal` are showing there. Is it possible that the reported line numbers in malloc.c are inaccurate or for a different source than the one I am looking at?


Is there a way to downgrade libc version on Ubuntu 22.04 to study how the performance/perf results change?


> >

> > The external name is wcstold or wcstold_l.  If your application isn't

> > calling that, the profiling data is wrong.  You might find out by

> > setting a breakpoint or probe on the function.

> >

> > Thanks,

> > Florian

> >