From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id DF50A1F463 for ; Fri, 20 Dec 2019 21:20:48 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:from:subject:message-id:date :mime-version:content-type:content-transfer-encoding; q=dns; s= default; b=X50DBXVdscSSOSiNyCALInCj0O0zsj8KK6ZMwO+aLnIj/r+iuCq5E kBk+dI1UbcQK3XV45I6YqZZuJK2cBrjjRg3vWIqlYtHXJ20XXG7Uvzhw3HgWNBfX g6Lol807X+ihAEB+9O5oA71pDETUz9TIKrjHprQbBUHMc0yNUHrAf8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:from:subject:message-id:date :mime-version:content-type:content-transfer-encoding; s=default; bh=wXMTOLUpq1A7664/jN3EKMz83UY=; b=SxSKFp8clcs92QVCSnko+gJ7uS5o KCpUPmdwUT3ZzaBA6IaQzphgv5XPHyV0vZ4qTtCBQqrf36CJ8FJK1ohjO1uvv+cq JROyxOySDZnN2An+xtQacBS2PWpqDcYslQ7D0IDM4jDDgnanbH470glb09jLCgNE evMc1iwTSwkYwF4= Received: (qmail 19468 invoked by alias); 20 Dec 2019 21:20:46 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 19451 invoked by uid 89); 20 Dec 2019 21:20:46 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-delivery-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576876842; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=JMutKeLaZHLcbrZjIm1/WPiu2n0/TOH2UMMiVPjgPpY=; b=AMEfh61sirjiThJO7TMNOE9aZiMffLnpr9WUi+ijiLcqF6XhgrCziWyBoTZ9wGEM5nFGzS 0n3TBiGZXA7GAvkhCB4C75xt+xF7y2n3lHd89t7z9+10JEpu9UNmEuqzNBcBLy1+AByhAx AAMZyZl+ByiFq0B7tAu5gbKWoI+DJDc= To: "Gabriel F. T. Gomes" , DJ Delorie , libc-alpha , Gdb , Gary Benson Cc: Florian Weimer From: Carlos O'Donell Subject: Debugging containerized glibc tests with gdb (a developer use case for outside-of-container debugging). Message-ID: Date: Fri, 20 Dec 2019 16:20:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Gabriel, DJ, I have a question at the very end of this long email, please bear with me while I think you for your good work. I have a follow-on question that is harder, but I'll leave that for the new year. I'm working on a new test that verifies running localedef and writing to default paths. This is only possible with root in a container. I am debugging this test using the excellent infrastructure that we have now wired up via: - WAIT_FOR_DEBUGGER=1, which causes the container-side process to save it's own PID and required debugging commands to a gdb script and then wait for the debugger to attach using the self-generated script. - debugglibc.sh's new -c option which does all the work of starting the test in the container and then running the tests gdb script. This works swimmingly. It's really easy to debug a containerized test that you're writing. With one command I'm right into the process running in the container and I can debug what's going on. [carlos@athas glibc-gr-localedef]$ ./debugglibc.sh -c locale/tst-localedef-path-norm Debugging glibc... Build directory : /home/carlos/build/glibc-gr-localedef/ Source directory : /mnt/ssd/carlos/src/glibc-gr-localedef GLIBC Testcase : locale/tst-localedef-path-norm GDB Commands : /home/carlos/build/glibc-gr-localedef/debugglibc.gdb Env vars : Waiting for debugger, test process is pid 32512 gdb -x locale/tst-localedef-path-norm.gdb GNU gdb (GDB) Fedora 8.3-7.fc30 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word". warning: Could not load shared library symbols for /home/carlos/build/glibc-gr-localedef/elf/ld.so. Do you need "set solib-search-path" or "set sysroot"? warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable. Connect to gdbserver inside the container. __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7ffcfe31e590, rem=rem@entry=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:75 75 return (INTERNAL_SYSCALL_ERROR_P (r, err) My question: Why did gdb say "Could not load shared library symbols for .../ld.so"? We fed it all the information it needed AFAIK. In debugglibc.sh we effectively ran this: ~~~ # Use testrun.sh to start the test case with WAIT_FOR_DEBUGGER=1, then # automatically attach GDB to it. WAIT_FOR_DEBUGGER=1 /home/carlos/build/glibc-gr-localedef/testrun.sh --tool=container ${TESTCASE} & gdb -x ${TESTCASE}.gdb ~~~ In ${TESTCASE}.gdb we ran this: ~~~ set sysroot /home/carlos/build/glibc-gr-localedef/testroot.root file file locale/tst-localedef-path-norm symbol-file locale/tst-localedef-path-norm exec-file locale/tst-localedef-path-norm attach 32512 set wait_for_debugger = 0 ~~~ Did we miss anything? Any thoughts? In test-container.c we mount $srcdir and $objdir into the same absolute paths inside the container, so ld.so should be accessible from the same absolute paths. If we fail those mounts we immediately fail the test with FAIL_EXIT1. Note: You can also try './debugglibc.sh -c elf/tst-ldconfig-bad-aux-cache' to look at similar behaviour from an existing test. -- Cheers, Carlos.