From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YktCB8Y2/WFULQAAWB0awg (envelope-from ) for ; Fri, 04 Feb 2022 09:23:02 -0500 Received: by simark.ca (Postfix, from userid 112) id 0CB531F3BA; Fri, 4 Feb 2022 09:23:02 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 908FE1ECEB for ; Fri, 4 Feb 2022 09:23:01 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1183F3858D3C for ; Fri, 4 Feb 2022 14:23:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1183F3858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1643984581; bh=zfaOObBGEWeAdI5rr1d6+OtQ+Ry2kEjsvUyeYHEj22E=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=X1MsZiHWZvVTEuXp+Z6/GiGBtZNUQb0VDBQfgW8x4lWasiEIYsS1MbQt4awNgAmZR yq4IPI03qSfhaD9YBnqnsBrJOZKVi6W4Y3TMRGHQesdGUbnRuvihTdstUx0RApEkwm feZSfOXs6hIKlLgAiT0YG7gs1wzqlE4pzto+rvQg= 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) To: Jacob Kroon 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-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: , From: Florian Weimer via Gdb Reply-To: Florian Weimer Cc: Jacob Kroon via Gdb Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" * 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