From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 03CBE3858D20 for ; Fri, 4 Feb 2022 14:22:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03CBE3858D20 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-396-snkjijO7MPO_EIw3jjNk6A-1; Fri, 04 Feb 2022 09:22:30 -0500 X-MC-Unique: snkjijO7MPO_EIw3jjNk6A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C8622185302B; Fri, 4 Feb 2022 14:22:29 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.205]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1DBC77C0EA; Fri, 4 Feb 2022 14:22:28 +0000 (UTC) From: Florian Weimer To: Jacob Kroon Cc: Jacob Kroon via Gdb Subject: Re: Debugging ld.so in gdb References: <29e0ef71-4706-9b0f-2a68-e12c54120d8e@gmail.com> <8735kypwcd.fsf@oldenburg.str.redhat.com> Date: Fri, 04 Feb 2022 15:22:27 +0100 In-Reply-To: (Jacob Kroon's message of "Fri, 4 Feb 2022 15:09:42 +0100") Message-ID: <87y22qognw.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 14:22:37 -0000 * Jacob Kroon: > This is what I get, following the instructions above: > >> 171966 0x00007ffff7fd85a0 : mov 0x0(%r13),%rax >> 171967 0x00007ffff7fd85a4 : lea -0x8(%rax),%rdx >> 171968 0x00007ffff7fd85a8 : mov %rdx,0x0(%r13) >> 171969 0x00007ffff7fd85ac : mov %rbp,-0x8(%rax) >> 171970 0x00007ffff7fd85b0 : add $0x8,%rsp >> 171971 0x00007ffff7fd85b4 : pop %rbx >> 171972 0x00007ffff7fd85b5 : pop %rbp >> 171973 0x00007ffff7fd85b6 : pop %r12 >> 171974 0x00007ffff7fd85b8 : pop %r13 >> 171975 0x00007ffff7fd85ba : ret > > Does that make sense ? Any other information I can provide. This is with > glibc-2.34-24.fc35.x86_64, Fedora 35. This doesn't really make sense. There's probably some GDB option to get a longer trace. If it is crashing at the RET, it means that either code has been mapped over, or the stack has been corrupted. At the crash site, what does print *(void**)$rsp print? disassemble *(void**)$rsp could also be interesting. Thanks, Florian