Где выполняется реализация strlen () в GCC?

Может ли кто-нибудь указать мне определение strlen() в GCC? Я был выпущен в июле 2005 года в течение почти полчаса (в то время как Googling как сумасшедший), и я не могу найти, где фактически выполняется strlen() .

Вы должны искать в glibc, а не в GCC – это, по-видимому, определено в strlen.c – вот ссылка на strlen.c для glibc версии 2.7 … И вот ссылка на repository glibc SVN онлайн для strlen. c .

Причина, по которой вы должны смотреть glibc, а не gcc:

Библиотека GNU C используется как библиотека C в системе GNU и большинстве систем с kernelм Linux.

Я понимаю, что этот вопрос составляет 4 года, но gcc часто будет включать свою собственную копию strlen, если вы не #include и ни один из ответов (включая принятый ответ) для этого не учитывается. Если вы забудете, вы получите предупреждение:

file_name:line_number: warning: incompatible implicit declaration of built-in function 'strlen'

и gcc будет встроить свою копию, которая на x86 является вариантом resnz scasb asm, если вы не передадите -Werror или -fno-builtin. Файлы, связанные с этим, находятся в файле gcc/config//.{c,md}

Он также контролируется gcc / builtins.c. В случае, если вам интересно, как и как оптимизирован strlen () для константы, см. Функцию, определенную как tree c_strlen(tree src, int only_value) в этом файле. Он также контролирует, как strlen (среди других) расширяется и складывается (на основе ранее упомянутой конфигурации / платформы)

Вот реализация bsd

 size_t strlen(const char *str) { const char *s; for (s = str; *s; ++s) ; return (s - str); } 

Это то, что вы ищите? strlen () . Для получения дополнительной информации см. Репозиторий git . На странице ресурсов glibc есть ссылки на репозитории git, если вы хотите их захватить, а не смотреть на веб-представление.

Хотя исходный плакат, возможно, не знал этого или искал это, gcc внутренне строит ряд так называемых «встроенных» c-функций, которые он сам определяет, включая некоторые функции mem * () и (в зависимости от gcc версия) strlen. В таких случаях версия библиотеки по существу никогда не используется, и указание человека на версию в glibc не является строго правильным. (Он делает это по соображениям производительности – в дополнение к улучшению, которое делает сама встраивание, gcc «знает» определенные вещи о функциях, когда он их предоставляет, например, что strlen является чистой функцией и что он может таким образом оптимизировать многократные вызовы или в случае функций mem * (), которые не имеют псевдонимов.)

Для получения дополнительной информации об этом см. http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html.

Поиск Google Code – хорошая отправная точка для таких вопросов. Они обычно указывают на различные источники и реализации функции.

В вашем конкретном случае: GoogleCodeSearch (strlen)

Поиск Google Code был полностью закрыт в марте 2013 года

определен в glibc / string / strlen.c

 #include  #include  #undef strlen #ifndef STRLEN # define STRLEN strlen #endif /* Return the length of the null-terminated string STR. Scan for the null terminator quickly by testing four bytes at a time. */ size_t STRLEN (const char *str) { const char *char_ptr; const unsigned long int *longword_ptr; unsigned long int longword, himagic, lomagic; /* Handle the first few characters by reading one character at a time. Do this until CHAR_PTR is aligned on a longword boundary. */ for (char_ptr = str; ((unsigned long int) char_ptr & (sizeof (longword) - 1)) != 0; ++char_ptr) if (*char_ptr == '\0') return char_ptr - str; /* All these elucidatory comments refer to 4-byte longwords, but the theory applies equally well to 8-byte longwords. */ longword_ptr = (unsigned long int *) char_ptr; /* Bits 31, 24, 16, and 8 of this number are zero. Call these bits the "holes." Note that there is a hole just to the left of each byte, with an extra at the end: bits: 01111110 11111110 11111110 11111111 bytes: AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD The 1-bits make sure that carries propagate to the next 0-bit. The 0-bits provide holes for carries to fall into. */ himagic = 0x80808080L; lomagic = 0x01010101L; if (sizeof (longword) > 4) { /* 64-bit version of the magic. */ /* Do the shift in two steps to avoid a warning if long has 32 bits. */ himagic = ((himagic << 16) << 16) | himagic; lomagic = ((lomagic << 16) << 16) | lomagic; } if (sizeof (longword) > 8) abort (); /* Instead of the traditional loop which tests each character, we will test a longword at a time. The tricky part is testing if *any of the four* bytes in the longword in question are zero. */ for (;;) { longword = *longword_ptr++; if (((longword - lomagic) & ~longword & himagic) != 0) { /* Which of the bytes was the zero? If none of them were, it was a misfire; continue the search. */ const char *cp = (const char *) (longword_ptr - 1); if (cp[0] == 0) return cp - str; if (cp[1] == 0) return cp - str + 1; if (cp[2] == 0) return cp - str + 2; if (cp[3] == 0) return cp - str + 3; if (sizeof (longword) > 4) { if (cp[4] == 0) return cp - str + 4; if (cp[5] == 0) return cp - str + 5; if (cp[6] == 0) return cp - str + 6; if (cp[7] == 0) return cp - str + 7; } } } } libc_hidden_builtin_def (strlen) 

Я понимаю, что это старый вопрос, вы можете найти источники ядра Linux в github здесь , а 32-разрядную реализацию для strlen () можно найти в strlen_32.c на github. Указанный файл имеет эту реализацию.

 #include  #include  #include  size_t strlen(const char *s) { /* Get an aligned pointer. */ const uintptr_t s_int = (uintptr_t) s; const uint32_t *p = (const uint32_t *)(s_int & -4); /* Read the first word, but force bytes before the string to be nonzero. * This expression works because we know shift counts are taken mod 32. */ uint32_t v = *p | ((1 << (s_int << 3)) - 1); uint32_t bits; while ((bits = __insn_seqb(v, 0)) == 0) v = *++p; return ((const char *)p) + (__insn_ctz(bits) >> 3) - s; } EXPORT_SYMBOL(strlen); 

Вы можете использовать этот код, тем проще, тем лучше!

 size_t Strlen ( const char * _str ) { size_t i = 0; while(_str[i++]); return i; } в size_t Strlen ( const char * _str ) { size_t i = 0; while(_str[i++]); return i; } 

glibc 2.26 имеет несколько оптимизированных вручную сборочных реализаций strlen

Начиная с glibc-2.26 , быстро:

 git ls-files | grep strlen.S 

в дереве glibc показано десяток сборных ручных оптимизированных реализаций для всех основных арков и вариаций.

В частности, только x86_64 имеет 3 варианта:

 sysdeps/x86_64/multiarch/strlen-avx2.S sysdeps/x86_64/multiarch/strlen-sse2.S sysdeps/x86_64/strlen.S 

Быстрый и грязный способ определить, какой из них используется, – это отладить тестовую программу:

 #include  #include  #include  #include  int main(void) { size_t size = 0x80000000, i, result; char *s = malloc(size); for (i = 0; i < size; ++i) s[i] = 'a'; s[size - 1] = '\0'; result = strlen(s); assert(result == size - 1); return EXIT_SUCCESS; } 

скомпилировано с:

 gcc -ggdb3 -std=c99 -O0 ac 

С летучей мыши:

 disass main 

содержит:

 callq 0x555555554590  

поэтому вызывается версия libc.

После того, как несколько инструкций уровня si вступают в это, GDB достигает:

 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:52 52 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory. 

который говорит мне, что был использован strlen-avx2.S .

Затем я подтверждаю:

 disass __strlen_avx2 

и сравните parsingку с источником glibc.

Неудивительно, что была использована версия AVX2, так как у меня есть процессор i7-7820HQ с датой запуска Q1 2017 и AVX2, а AVX2 - самая передовая из сборных версий , с датой запуска Q2 2013, в то время как SSE2 намного больше древний с 2004 года.

Вот откуда взялась большая часть хардкорности glibc: у нее много усовершенствованного рукописного ассемблерного кода.

Протестировано в Ubuntu 17.10, gcc 7.2.0, glibc 2.26.

-O3

TODO: с -O3 , gcc не использует strlen glibc, он просто генерирует встроенную сборку, о которой говорится по адресу: https://stackoverflow.com/a/19885891/895245

Это потому, что он может оптимизировать еще лучше? Но его вывод не содержит инструкций AVX2, поэтому я чувствую, что это не так.

https://www.gnu.org/software/gcc/projects/optimize.html упоминает:

Недостатки оптимизатора GCC

glibc имеет встроенные ассемблерные версии различных строковых функций; GCC имеет некоторые, но не обязательно одни и те же архитектуры. Дополнительные элементы optab, такие как ffs и strlen, могут быть предоставлены для нескольких функций, включая memset, strchr, strcpy и strrchr.

Мои простые тесты показывают, что версия -O3 самом деле быстрее, поэтому GCC сделал правильный выбор.

На вопрос: https://www.quora.com/unanswered/How-does-GCC-know-that-its-builtin-implementation-of-strlen-is-faster-than-glibcs-when-using-optimization-level -O3