[ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later

[jakubjelinek]

Summary

Running sanitized 32-bit x86 programs on glibc 2.27 crashes at startup, with:

ERROR: AddressSanitizer: SEGV on unknown address 0xf7a8a250 (pc 0xf7f807f4 bp 0xff969fc8 sp 0xff969f7c T16777215)
The signal is caused by a WRITE memory access.
#0 0xf7f807f3 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x127f3)
#1 0xf7a92599  (/lib/libasan.so.5+0x112599)
#2 0xf7a80737  (/lib/libasan.so.5+0x100737)
#3 0xf7f7e14f in _dl_init (/lib/ld-linux.so.2+0x1014f)
#4 0xf7f6eb49  (/lib/ld-linux.so.2+0xb49)

The problem is that glibc changed the calling convention for the GLIBC_PRIVATE
symbol that sanitizer uses (even when it should not, GLIBC_PRIVATE is exactly
for symbols that can change at any time, be removed etc.), see
https://sourceware.org/ml/libc-alpha/2017-08/msg00497.html

Fixes https://github.com/google/sanitizers/issues/954

[jakubjelinek]

glibc 2.27 has added the glob@@GLIBC_2.27 symbols approx. one month after these internal_function changes, so it is closer to that than e.g. trying to parse confstr for glibc 2.27 and later, and is also smaller than trying to parse the confstr string.

[kcc]

Is this related to https://github.com/google/sanitizers/issues/914 or this is another problem?
(also: https://sourceware.org/ml/libc-alpha/2018-02/msg00567.html)

even when it should not

Any chance to get https://sourceware.org/glibc/wiki/ThreadPropertiesAPI moving?

Is a test possible? Or is this covered by an existing test? Which one?

I'm OOO for a few days, Vitaly, please review further.

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

205

nested ifdefs? I'd prefer to avoid them. Move this code into a separate function, maybe?

206

This code uses // comments.

[vitalybuka]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

161

Do we need to check for this?
Maybe just always go for dlvsym(RTLD_NEXT, "glob", "GLIBC_2.27") ?

205

maybe?

template<typename GetTlsType>
void GetTlsImpl() {
   void *get_tls_static_info_ptr = dlsym(RTLD_NEXT, "_dl_get_tls_static_info");
   GetTlsType get_tls;
    CHECK_EQ(sizeof(get_tls), sizeof(get_tls_static_info_ptr));
    internal_memcpy(&get_tls, &get_tls_static_info_ptr,
                    sizeof(get_tls_static_info_ptr));
    CHECK_NE(get_tls, 0);
    get_tls(&tls_size, &tls_align);
}

static void GetTls() {
#if defined(__i386__)
   if (!dlvsym(RTLD_NEXT, "glob", "GLIBC_2.27"))
     return GetTlsImpl<>;
#endif
 return GetTlsImpl<>
}

[jakubjelinek]

In D44623#1042762, @kcc wrote:

Is this related to https://github.com/google/sanitizers/issues/914 or this is another problem?

Dunno, that issue talks about glibc 2.25, I'm not aware of issues with glibc 2.25, this one is about 2.27.

Any chance to get https://sourceware.org/glibc/wiki/ThreadPropertiesAPI moving?

That is a question for the glibc people, I'm out of the glibc business for 10+ years already.

[jakubjelinek]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

161

It is not strictly needed, just an optimization. At least in GCC, if somebody configures the compiler against some version of binutils, glibc etc., we assume that at runtime that version or newer of it is available, so it is an optimization; if somebody configures against glibc 2.27+, it avoids the dlvsym calls on startup of every sanitized app.

205

Attributes on function pointers passed to templates have historically been problematic in several compilers, so I think it is better to avoid that.
E.g. clang++ 6.0.0 r319306 rejects:

typedef void (*F) (int) __attribute__((regparm (3), stdcall));
typedef void (*G) (int);

template <typename T>
void foo (T x)
{
  x (0);
}

void
bar (F x, G y)
{
  foo (x);
  foo (y);
}

g++ before 5 emit 2 different instantiations with the same mangled name and so it fails to compile, g++ 5 ICEs on it, only 6+ handles it right and provide different mangled names for both.
So, if it would be a template, it would need to have 2 different classes that would contain say a typedef in them and that is what the template would call.

[vitalybuka]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

161

#if defined(__i386__) && (!defined(__GLIBC_PREREQ) || !__GLIBC_PREREQ(2, 27))
#define CHECK_GET_TLS_STATIC_INFO_VERSION 1
#else
#define CHECK_GET_TLS_STATIC_INFO_VERSION 0
#endif

...

if (CHECK_GET_TLS_STATIC_INFO_VERSION && !dlvsym(RTLD_NEXT, "glob", "GLIBC_2.27")) {

[Lekensteyn]

Is a test possible? Or is this covered by an existing test? Which one?

When unpatched, all 781 i386 tests fail with glibc 2.27. I think that should be good enough :-)

Is this related to https://github.com/google/sanitizers/issues/914 or this is another problem?

Could be related, but it can be fixed independently as it is just a different calling convention. See https://github.com/google/sanitizers/issues/954

As mentioned in the comments in that bug, would it be worth factoring out the confstr minor/patch version check from ThreadDescriptorSize and reusing that function here instead of calling dlvsym? Glibc 2.27 is currently released as stable, so pre-2.27 versions after 2.26 should be nearly non-existent right?

[jakubjelinek]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

161

This will not compile if __GLIBC_PREREQ is not defined, it has to be nested #if or __GLIBC_PREREQ needs to be always defined.

[jakubjelinek]

Updated patch, which uses a template with 2 support classes to avoid some code duplication. I must say that I find

#ifndef __GLIBC_PREREQ
# define __GLIBC_PREREQ(x, y) 0
#endif

easier to read over the longer sequence of #ifs, and as I said earlier, the proposed

#if defined(__i386__) && (!defined(__GLIBC_PREREQ) || !__GLIBC_PREREQ(2, 27))

is not valid C/C++ if __GLIBC_PREREQ macro is not defined.

[Lekensteyn]

Other than the inline lint warnings, it looks good to me. (The patch is also missing the directory, but it applies otherwise.)

I tried this and the check-sanitizer tests pass with glibc 2.27. A simple 32-bit test program also passes both glibc 2.27 and 2.26.

sanitizer_linux_libcdep.cc

196 ↗

(On Diff #145936)

Lint complains here:

sanitizer_linux_libcdep.cc:196:  Namespace should be terminated with "// namespace"  [readability/namespace] [5]

210 ↗

(On Diff #145936)

More lint complaints:

sanitizer_linux_libcdep.cc:210:  Tab found; better to use spaces  [whitespace/tab] [1]
sanitizer_linux_libcdep.cc:213:  Tab found; better to use spaces  [whitespace/tab] [1]

[Lekensteyn]

LGTM, are others also happy with this?

[vitalybuka]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

174

Do we need this if we do runtime check anyway?
We can't get into GetTlsStaticInfoRegparmCall with CHECK_GET_TLS_STATIC_INFO_VERSION == 0

238

Is this the same as __GLIBC_PREREQ()

[vitalybuka]

https://reviews.llvm.org/D46638
@Lekensteyn Which one are we going to complete

[jakubjelinek]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

174

If you mean the __GLIBC_PREREQ, that is an optimization to avoid doing the runtime check if we know the check is unnecessary.
If the CallGetTls<GetTlsStaticInfoCall>(get_tls_static_info_ptr, ...); call is not ifdefed out through preprocessor, then yes, it is needed.

238

confstr is a runtime check, __GLIBC_PREREQ is a compile time check.

[vitalybuka]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

174

This initialization once per process not thread, so I don't see reasons to complicate code for such minor improvement.

238

Right,
than this is should be similar to dlvsym(RTLD_NEXT, "glob", "GLIBC_2.27"))?

[Lekensteyn]

@vitalybuka I think that this patch is making good progress, so I abandoned the other patch.

If forward compatibility is important, I would change the __GLIBC_PREREQ check. Otherwise it looks ready to me.

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

174

For forward compatibility, what about dropping __GLIBC_PREREQ? E.g.:

#if defined(__i386__) && defined(__GLIBC_PREREQ)
# define CHECK_GET_TLS_STATIC_INFO_VERSION 1
# define DL_INTERNAL_FUNCTIOn ...
#else
# define CHECK_GET_TLS_STATIC_INFO_VERSION 0
#endif

Then a binary built with clang on glibc 2.26 will still work correctly with glibc 2.27.

238

It is not possible, there are multiple versions being checked. D46638 tried to reuse this version check with the above, but that failed because confstr is intercepted by MSAN.

The better alternative seems gnu_get_libc_version, but there were concerns about dlsym being expensive. Not that big of a deal imo, but as the current patch looks fine to me, I dropped the other patch.

[vitalybuka]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

185

Maybe just inline it here:

typedef void (*get_tls_func)(size_t*, size_t*) __attribute__((regparm(3), stdcall))

[kcc]

Is this code review stuck?

[jakubjelinek]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

185

That isn't possible. If you don't want ifdefs in the code, in particular the
​ if (CHECK_GET_TLS_STATIC_INFO_VERSION &&
​ !dlvsym(RTLD_NEXT, "glob", "GLIBC_2.27"))
​ CallGetTls<GetTlsStaticInfoRegparmCall>(get_tls_static_info_ptr,
​ &tls_size, &tls_align);
code to be ifdefed out if not i?86, then the GetTlsStaticInfoRegparmCall class must be defined even for other targets, even when after optimizations it will not be really used, and so you can't use i?86 specific attributes in there.

[petarj]

What's the status of this change?

I can see five failures after it is applied. Here they are:

Failing Tests (5):

  Builtins-i386-linux :: divsc3_test.c
  LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/use_tls_dynamic.cc
  LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/use_tls_dynamic.cc
  MemorySanitizer-X86_64 :: dtls_test.c
  MemorySanitizer-lld-X86_64 :: dtls_test.c

Expected Passes    : 43861
Expected Failures  : 221
Unsupported Tests  : 1992
Unexpected Failures: 5

[Lekensteyn]

It has been reviewed and is ready for landing.

Could you push it @jakubjelinek? If nobody takes care of it I'll try to merge it later.

[jakubjelinek]

In D44623#1126626, @Lekensteyn wrote:

Could you push it @jakubjelinek? If nobody takes care of it I'll try to merge it later.

I don't have an account. Can somebody push it for me? Thanks.

[Lekensteyn]

I'll perform some final tests and push it once it passes.

[Lekensteyn]

In D44623#1126624, @petarj wrote:

I can see five failures after it is applied. Here they are:

Failing Tests (5):

  Builtins-i386-linux :: divsc3_test.c
  LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/use_tls_dynamic.cc
  LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/use_tls_dynamic.cc
  MemorySanitizer-X86_64 :: dtls_test.c
  MemorySanitizer-lld-X86_64 :: dtls_test.c

Expected Passes    : 43861
Expected Failures  : 221
Unsupported Tests  : 1992
Unexpected Failures: 5

Are these tests passing with this patch reverted? Edit 3: no, the same tests (plus more i386 tests failures). Tested with glibc 2.27-3 on Arch Linux and:

• r334302 llvm
• r334272 projects/compiler-rt
• r334281 tools/clang
• r334287 tools/clang/tools/extra

I just ran check-lsan and can confirm the test failure:

******************** TEST 'LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/use_tls_dynamic.cc' FAILED ********************
Indirect leak of 1337 byte(s) in 1 object(s) allocated from:
    #0 0x4ec28f in __interceptor_malloc projects/compiler-rt/lib/asan/asan_malloc_linux.cc:121:3
    #1 0x52af83 in main projects/compiler-rt/test/lsan/TestCases/Linux/use_tls_dynamic.cc:27:13
    #2 0x7ffa49a4006a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)

Objects leaked above:
0x61a000000680 (1337 bytes)

-----------------------------------------------------
Suppressions used:
  count      bytes template
      1    1048576 *tls_get_addr*
-----------------------------------------------------

Perhaps the new implementation leaks pointers on the stack, causing false positives?

If I run the reproducer from the linked issue (clang -g -fsanitize=address -m32 empty.c -o empty && ./empty), it crashes without this patch and passes with this patch applied. Building the binary on Arch Linux x86_64 (glib 2.27-3) and running it on Ubuntu 16.04 (glibc 2.23-0ubuntu10) still crashes though. That is expected with this version of the patch as it assumes that libc used for compiling clang matches the runtime libc.

(D46638 was an alternative version that performs a runtime check, but it would need more changes so the current patch seems a good start.)

Edit:

Failing Tests (21):
    AddressSanitizer-Unit :: ./Asan-i386-calls-Dynamic-Test/AddressSanitizer.asm_load_store
    AddressSanitizer-Unit :: ./Asan-i386-calls-Dynamic-Test/AddressSanitizer.asm_rep_movs
    AddressSanitizer-Unit :: ./Asan-i386-calls-Dynamic-Test/AddressSanitizer.asm_rw
    AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.asm_load_store
    AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.asm_rep_movs
    AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.asm_rw
    AddressSanitizer-Unit :: ./Asan-i386-inline-Dynamic-Test/AddressSanitizer.asm_load_store
    AddressSanitizer-Unit :: ./Asan-i386-inline-Dynamic-Test/AddressSanitizer.asm_rep_movs
    AddressSanitizer-Unit :: ./Asan-i386-inline-Dynamic-Test/AddressSanitizer.asm_rw
    AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.asm_load_store
    AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.asm_rep_movs
    AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.asm_rw
    Builtins-i386-linux :: divsc3_test.c
    DataFlowSanitizer-x86_64 :: custom.cc
    LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/use_tls_dynamic.cc
    LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/use_tls_dynamic.cc
    MemorySanitizer-X86_64 :: Linux/sunrpc.cc
    MemorySanitizer-X86_64 :: Linux/sunrpc_bytes.cc
    MemorySanitizer-X86_64 :: Linux/sunrpc_string.cc
    MemorySanitizer-X86_64 :: dtls_test.c
    ThreadSanitizer-x86_64 :: sunrpc.cc

  Expected Passes    : 32752
  Expected Failures  : 112
  Unsupported Tests  : 11941
  Unexpected Failures: 21

• AddressSanitizer-Unit: AddressSanitizer: nested bug in the same thread, aborting. Edit 2: this segfaults in ErrorDescription() { internal_memset(this, 0, sizeof(*this)); }:

#0  0x080b2e04 in __asan::ErrorGeneric::ErrorGeneric (this=0xffffbac0, tid=0, pc_=136535675, bp_=4294952244, sp_=4294952232, addr=4102034300, is_write_=false, access_size_=4) at projects/compiler-rt/lib/asan/asan_errors.cc:368
#1  0x0818b479 in __asan::ReportGenericError (pc=136535675, bp=4294952244, sp=4294952232, addr=4102034300, is_write=false, access_size=4, exp=0, fatal=true) at projects/compiler-rt/lib/asan/asan_report.cc:453
#2  0x0818c37a in __asan::__asan_report_load4 (addr=4102034300) at projects/compiler-rt/lib/asan/asan_rtl.cc:114
#3  0x08235e7b in AsmLoad () at projects/compiler-rt/lib/asan/tests/asan_asm_test.cc:181
#4  TestBody () at projects/compiler-rt/lib/asan/tests/asan_asm_test.cc:215

• divsc3_test.c exited with 1, but no other output.
• The custom.cc failure: custom.cc.tmp: projects/compiler-rt/test/dfsan/custom.cc:429: void test_gethostname(): Assertion 0 == dfsan_read_label(buf + 2, 2)' failed.`
• use_tls_dynamic failed as noted above (memleak report)
• sunrpc tests fail due to: projects/compiler-rt/test/tsan/sunrpc.cc:4:10: fatal error: 'rpc/types.h' file not found. Reported at https://github.com/google/sanitizers/issues/974
• The dtls_test.c test failure:

MemorySanitizer: use-of-uninitialized-value
    #0 0x493e57 in Thread1 /home/peter/projects/llvm/projects/compiler-rt/test/msan/dtls_test.c:25:7
    #1 0x7f329e96c074 in start_thread (/usr/lib/libpthread.so.0+0x7074)
    #2 0x7f329dce853e in __GI___clone (/usr/lib/libc.so.6+0xf853e)

[Lekensteyn]

Oops, I typoed "Differential Revision". Closing manually.

Thanks for the patch, all tests are still passing!

[vitalybuka]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

208

This breaks lsan:

==211269==Sanitizer CHECK failed: compiler-rt/lib/lsan/lsan_interceptors.cc:54 ((!lsan_init_is_running)) != (0) (0, 0)

dlvsym calls malloc when lsan is not initialized

[Lekensteyn]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

208

Ok, I can reproduce this with -fsanitize=leak (but not -fsanitize=address), but only in this setting:

• #define CHECK_GET_TLS_STATIC_INFO_VERSION 1
• dlvsym(RTLD_NEXT, "globsomethingnonexisting", ...)

This presumably affects only 32-bit libraries with glibc before 2.27.

I did not see any buildbot complain on this though, how did you catch this issue? It seems a lack of test coverage.

If it does not need an immediate fix (buildbots are not blocked), I could try to work on using the confstr patch again to dynamically query the glibc version which should avoid malloc. Otherwise the patch needs to be reverted.

[vitalybuka]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

208

-fsanitize=leak (but not -fsanitize=address), but only in this setting:

Asan malloc interceptor will use internal buffer for allocations which happen before asan is initialized.

I did not see any buildbot complain on this though, how did you catch this issue? It seems a lack of test coverage

Looks like bots have no i386 libs installed. I will try to fix that.

[vitalybuka]

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

208

D48265 works for me

compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc

bool SetEnv(const char *name, const char *value) {
   setenv_ft setenv_f;
   CHECK_EQ(sizeof(setenv_f), sizeof(f));
   internal_memcpy(&setenv_f, &f, sizeof(f));
   return setenv_f(name, value, 1) == 0;
 }
 #endif
 
 #if !SANITIZER_FREEBSD && !SANITIZER_ANDROID && !SANITIZER_GO &&               \
     !SANITIZER_NETBSD && !SANITIZER_OPENBSD && !SANITIZER_SOLARIS
 static uptr g_tls_size;
 
 #ifdef __i386__
+# ifndef __GLIBC_PREREQ
+#  define CHECK_GET_TLS_STATIC_INFO_VERSION 1
+# else
+#  define CHECK_GET_TLS_STATIC_INFO_VERSION (!__GLIBC_PREREQ(2, 27))
+# endif
+#else
+# define CHECK_GET_TLS_STATIC_INFO_VERSION 0
+#endif
+
+#if CHECK_GET_TLS_STATIC_INFO_VERSION
 # define DL_INTERNAL_FUNCTION __attribute__((regparm(3), stdcall))
 #else
 # define DL_INTERNAL_FUNCTION
 #endif
 
+namespace {
+struct GetTlsStaticInfoCall {
+  typedef void (*get_tls_func)(size_t*, size_t*);
+};
+struct GetTlsStaticInfoRegparmCall {
+  typedef void (*get_tls_func)(size_t*, size_t*) DL_INTERNAL_FUNCTION;
+};
+
+template <typename T>
+void CallGetTls(void* ptr, size_t* size, size_t* align) {
+  typename T::get_tls_func get_tls;
+  CHECK_EQ(sizeof(get_tls), sizeof(ptr));
+  internal_memcpy(&get_tls, &ptr, sizeof(ptr));
+  CHECK_NE(get_tls, 0);
+  get_tls(size, align);
+}
+}  // namespace
+
 void InitTlsSize() {
   // all current supported platforms have 16 bytes stack alignment
   const size_t kStackAlign = 16;
-  typedef void (*get_tls_func)(size_t*, size_t*) DL_INTERNAL_FUNCTION;
-  get_tls_func get_tls;
   void *get_tls_static_info_ptr = dlsym(RTLD_NEXT, "_dl_get_tls_static_info");
-  CHECK_EQ(sizeof(get_tls), sizeof(get_tls_static_info_ptr));
-  internal_memcpy(&get_tls, &get_tls_static_info_ptr,
-                  sizeof(get_tls_static_info_ptr));
-  CHECK_NE(get_tls, 0);
   size_t tls_size = 0;
   size_t tls_align = 0;
-  get_tls(&tls_size, &tls_align);
+  // On i?86, _dl_get_tls_static_info used to be internal_function, i.e.
+  // __attribute__((regparm(3), stdcall)) before glibc 2.27 and is normal
+  // function in 2.27 and later.
+  if (CHECK_GET_TLS_STATIC_INFO_VERSION &&
+      !dlvsym(RTLD_NEXT, "glob", "GLIBC_2.27"))
+    CallGetTls<GetTlsStaticInfoRegparmCall>(get_tls_static_info_ptr,
+                                            &tls_size, &tls_align);
+  else
+    CallGetTls<GetTlsStaticInfoCall>(get_tls_static_info_ptr,
+                                     &tls_size, &tls_align);
   if (tls_align < kStackAlign)
     tls_align = kStackAlign;
   g_tls_size = RoundUpTo(tls_size, tls_align);
 }
 #else
 void InitTlsSize() { }
 #endif  // !SANITIZER_FREEBSD && !SANITIZER_ANDROID && !SANITIZER_GO &&
         // !SANITIZER_NETBSD && !SANITIZER_SOLARIS
 
 #if (defined(__x86_64__) || defined(__i386__) || defined(__mips__) ||          \
      defined(__aarch64__) || defined(__powerpc64__) || defined(__s390__) ||    \
      defined(__arm__)) &&                                                      \
     SANITIZER_LINUX && !SANITIZER_ANDROID
 // sizeof(struct pthread) from glibc.
 static atomic_uintptr_t thread_descriptor_size;
 
 uptr ThreadDescriptorSize() {
   uptr val = atomic_load_relaxed(&thread_descriptor_size);
   if (val)
     return val;
 #if defined(__x86_64__) || defined(__i386__) || defined(__arm__)
 #ifdef _CS_GNU_LIBC_VERSION
   char buf[64];
   uptr len = confstr(_CS_GNU_LIBC_VERSION, buf, sizeof(buf));
   if (len < sizeof(buf) && internal_strncmp(buf, "glibc 2.", 8) == 0) {
     char *end;
     int minor = internal_simple_strtoll(buf + 8, &end, 10);
     if (end != buf + 8 && (*end == '\0' || *end == '.' || *end == '-')) {
       int patch = 0;
       if (*end == '.')
         // strtoll will return 0 if no valid conversion could be performed
         patch = internal_simple_strtoll(end + 1, nullptr, 10);