Re: [PATCH v4] Threaded grep

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 26, 2010, 15:28 UTC
Message-ID: <alpine.LFD.2.00.1001260728260.3574@localhost.localdomain>
In-Reply-To: <4c8ef71001260410l2afd2dbx17b6e216bd9e5d8@mail.gmail.com>

On Tue, 26 Jan 2010, Fredrik Kuivinen wrote:

> 
> I see the strlen in my profiles as well, but I haven't figured out
> where it comes from.

Looks like this in gdb:

#0  0x0000003e3687f2e0 in __strlen_sse2 () from /lib64/libc.so.6
#1  0x0000003e368c04c5 in regexec@@GLIBC_2.3.4 () from /lib64/libc.so.6
#2  0x000000000047677a in look_ahead (opt=<value optimized out>, 
    name=<value optimized out>, buf=<value optimized out>, 
    size=<value optimized out>, collect_hits=<value optimized out>)
    at grep.c:679
#3  grep_buffer_1 (opt=<value optimized out>, name=<value optimized out>, 
    buf=<value optimized out>, size=<value optimized out>, 
    collect_hits=<value optimized out>) at grep.c:790

so it's sadly internal to regex. It would be nice if there was a non-string interface to regexec (ie a "buffer + length" instead of a NUL-terminated string).

> If I use perf record -g I get

I suspect that libc isn't compiled with frame pointers, so call chains end up being unreliable.

		Linus