Wo ist die Implementierung von strlen() in GCC?

Kann mir jemand die Definition von zeigen strlen() im GCC? Ich suche jetzt seit ungefähr einer halben Stunde nach Version 4.4.2 (während ich wie verrückt google) und kann anscheinend nicht finden, wo strlen() tatsächlich umgesetzt wird.

Sie sollten in glibc suchen, nicht in GCC – es scheint in definiert zu sein strlen.c – Hier ist ein Link zu strlen.c für Glibc-Version 2.7… Und hier ist ein Link zu dem glibc SVN-Repository online für strlen.c.

Der Grund, den Sie sich ansehen sollten glibc und nicht gcc ist:

Als Bibliothek wird die GNU-C-Bibliothek verwendet das C-Bibliothek im GNU-System und den meisten Systemen mit dem Linux-Kernel.

Mir ist klar, dass diese Frage 4 Jahre alt ist, aber gcc wird sie oft enthalten besitzen Kopie von strlen, wenn Sie dies nicht tun #include <string.h> und keine der Antworten (einschließlich der akzeptierten Antwort) berücksichtigt dies. Wenn Sie es vergessen, erhalten Sie eine Warnung:

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

und gcc fügt seine Kopie ein, die auf x86 die Variante repnz scasb asm ist, es sei denn, Sie übergeben -Werror oder -fno-builtin. Die dazugehörigen Dateien sind in gcc/config/<platform>/<platform>.{c,md}

Es wird auch von gcc/builtins.c gesteuert. Falls Sie sich gefragt haben, ob und wie ein strlen() auf eine Konstante optimiert wurde, sehen Sie sich die Funktion definiert als an tree c_strlen(tree src, int only_value) in dieser Datei. Es steuert auch, wie strlen (unter anderem) erweitert und gefaltet wird (basierend auf der zuvor erwähnten Konfiguration/Plattform).

Hier ist die bsd Implementierung

size_t
strlen(const char *str)
{
        const char *s;

        for (s = str; *s; ++s)
                ;
        return (s - str);
}

definiert in glibc/string/strlen.c

#include <string.h>
#include <stdlib.h>

#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)

glibc 2.26 hat mehrere handoptimierte Assembler-Implementierungen von strlen

Ab glibc-2.26eine schnelle:

git ls-files | grep strlen.S

im Glibc-Baum zeigt ein Dutzend von Hand optimierte Implementierungen für alle wichtigen Bögen und Variationen.

Insbesondere x86_64 allein hat 3 Variationen:

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

Eine schnelle und schmutzige Methode, um festzustellen, welches verwendet wird, besteht darin, ein Testprogramm schrittweise zu debuggen:

#include <assert.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>

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;
}

zusammengestellt mit:

gcc -ggdb3 -std=c99 -O0 a.c

Abseits der Fledermaus:

disass main

enthält:

callq  0x555555554590 <strlen@plt>

also wird die libc-version aufgerufen.

Nach einigen si Anweisungsebene tritt in das ein, GDB erreicht:

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

was mir das sagt strlen-avx2.S wurde benutzt.

Dann bestätige ich weiter mit:

disass __strlen_avx2

und vergleichen Sie die Disassemblierung mit der Glibc-Quelle.

Es ist nicht verwunderlich, dass die AVX2-Version verwendet wurde, da ich eine habe i7-7820HQ CPU mit Startdatum Q1 2017 und AVX2-Unterstützung und AVX2 ist die am weitesten fortgeschrittene der Assembly-Implementierungen, mit dem Startdatum Q2 2013, während SSE2 ist viel älter von 2004.

Hier kommt ein großer Teil der Hardcoreness von glibc her: es hat viel Arch-optimierten, handgeschriebenen Assembler-Code.

Getestet in Ubuntu 17.10, gcc 7.2.0, glibc 2.26.

-O3

Zu tun mit -O3gcc verwendet nicht die von glibc strlengeneriert es nur eine Inline-Assembly, die unter https://stackoverflow.com/a/19885891/895245 erwähnt wird

Liegt es daran, dass es noch besser optimieren kann? Aber seine Ausgabe enthält keine AVX2-Anweisungen, daher denke ich, dass dies nicht der Fall ist.

https://www.gnu.org/software/gcc/projects/optimize.html erwähnt:

Mängel des Optimierers von GCC

glibc hat Inline-Assembler-Versionen verschiedener String-Funktionen; GCC hat einige, aber nicht unbedingt dieselben auf denselben Architekturen. Zusätzliche optab-Einträge, wie die für ffs und strlen, könnten für mehrere weitere Funktionen bereitgestellt werden, darunter memset, strchr, strcpy und strrchr.

Meine einfachen Tests zeigen, dass die -O3 Version ist tatsächlich schneller, also hat GCC die richtige Wahl getroffen.

Gefragt bei: https://www.quora.com/unanswered/How-does-gcc-now-that-its-builtin-implementation-of-strlen-is-faster-than-glibcs-when-using-optimization-level-O3

Obwohl der ursprüngliche Poster dies möglicherweise nicht wusste oder danach gesucht hat, fügt gcc intern eine Reihe sogenannter “eingebauter” c-Funktionen ein, die es selbst definiert, einschließlich einiger der mem*()-Funktionen und (abhängig von der gcc-Version) strlen. In solchen Fällen wird die Bibliotheksversion im Wesentlichen nie verwendet, und es ist streng genommen nicht korrekt, die Person auf die Version in glibc zu verweisen. (Es tut dies aus Leistungsgründen – zusätzlich zu der Verbesserung, die das Inlining selbst erzeugt, „weiß“ gcc bestimmte Dinge über die Funktionen, wenn es sie bereitstellt, wie zum Beispiel, dass strlen eine reine Funktion ist und dass es das kann mehrfache Aufrufe wegoptimieren, oder bei den mem*()-Funktionen, dass kein Aliasing stattfindet.)

Weitere Informationen hierzu finden Sie unter http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Suchst du danach? strlen() Quelle. Siehe die Git-Repository für mehr Informationen. Das glibc-Ressourcenseite enthält Links zu den Git-Repositories, wenn Sie sie abrufen möchten, anstatt sich die Webansicht anzusehen.