This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 00/12] x86/CET: The last 12 patches to enable Intel CET
On Fri, Jul 27, 2018 at 9:49 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 07/27/2018 06:47 PM, H.J. Lu wrote:
>>
>> On Fri, Jul 27, 2018 at 9:44 AM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>>>
>>> On 07/27/2018 06:37 PM, H.J. Lu wrote:
>>>
>>>>> We load datasz and then check for having encountered the last note.
>>>>> I'm
>>>>> checking a fix.
>>>>
>>>>
>>>>
>>>> How can I reproduce it?
>>>
>>>
>>>
>>> Perhaps it is only visible with an explicit invocation of the dynamic
>>> linker?
>>>
>>> I saw it while building GCC on Fedora rawhide. I've pushed my latest
>>> changes (commit a4a5659439698554d18b9f1ef56cbd86591e217b) to the
>>> distribution Git, even though they do not build. The valgrind check at
>>> the
>>> end of the build fails.
>>
>>
>> What is the command line to reproduce it with glibc build configured
>> with --enable-cet?
>
>
> This command is run inside the build directory:
>
> elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/valgrind --vgdb-error=1
> --track-origins=yes --error-exitcode=1 elf/ld.so --library-path
> .:elf:nptl:dlfcn /usr/bin/true
>
[hjl@gnu-cet-2 build-x86_64-linux]$ elf/ld.so --library-path
.:elf:nptl:dlfcn /usr/bin/valgrind --vgdb-error=1 --track-origins=yes
--error-exitcode=1 elf/ld.so --library-path .:elf:nptl:dlfcn
/usr/bin/true
==1086== Memcheck, a memory error detector
==1086== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1086== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1086== Command: elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/true
==1086==
==1086==
==1086== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==1086== /path/to/gdb elf/ld.so
==1086== and then give GDB the following command
==1086== target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=1086
==1086== --pid is optional if only one valgrind process is running
==1086==
==1086==
==1086== HEAP SUMMARY:
==1086== in use at exit: 0 bytes in 0 blocks
==1086== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1086==
==1086== All heap blocks were freed -- no leaks are possible
==1086==
==1086== For counts of detected and suppressed errors, rerun with: -v
==1086== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[hjl@gnu-cet-2 build-x86_64-linux]$ strace elf/ld.so
execve("elf/ld.so", ["elf/ld.so"], 0x7fff35c62fc0 /* 51 vars */) = 0
brk(NULL) = 0x7f0fb46ec000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffecf6aedf0) = 0
writev(2, [{iov_base="Usage: ld.so [OPTION]... EXECUTA"...,
iov_len=1373}], 1Usage: ld.so [OPTION]... EXECUTABLE-FILE
[ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file. This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it. You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run. This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.
--list list all dependencies and how they are resolved
--verify verify that given object really is a dynamically linked
object we can handle
--inhibit-cache Do not use /etc/ld.so.cache
--library-path PATH use given PATH instead of content of the environment
variable LD_LIBRARY_PATH
--inhibit-rpath LIST ignore RUNPATH and RPATH information in object names
in LIST
--audit LIST use objects named in LIST as auditors
) = 1373
exit_group(127) = ?
+++ exited with 127 +++
[hjl@gnu-cet-2 build-x86_64-linux]$
--
H.J.