From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4060 invoked by alias); 6 Jan 2012 19:54:17 -0000 Received: (qmail 4048 invoked by uid 22791); 6 Jan 2012 19:54:16 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from caibbdcaaaaf.dreamhost.com (HELO homiemail-a55.g.dreamhost.com) (208.113.200.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 19:54:03 +0000 Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 0771012C0DB; Fri, 6 Jan 2012 11:54:03 -0800 (PST) Received: from redwood.eagercon.com (c-76-102-3-160.hsd1.ca.comcast.net [76.102.3.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eager@eagerm.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id D009D12C0D4; Fri, 6 Jan 2012 11:54:02 -0800 (PST) Message-ID: <4F075159.5090508@eagerm.com> Date: Fri, 06 Jan 2012 19:54:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: gdb@sourceware.org CC: Alan Modra Subject: PowerPC SecurePLT - stepping into library function Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00019.txt.bz2 GDB doesn't step into functions in a shared library on PowerPC which are compiled with -msecure-PLT. It steps over the function like the "next" command. It looks like GDB makes a number of assumptions based on the original SVR4 PLT design and which are not valid with securePLT. One assumption is that the PLT stub is in the .plt section. Another is that the symbol for the PLT stub will have an STT_ENTRY in the symtab. It seems that the best way to fix this would be to create a new OSABI sniffer for SecurePLT which identifies that the executable was compiled with -msecurePLT. One issue is how to identify these programs. The Power Arch 32-bit ABI (Sect 5.2.5.2, note at end) says that these will have R_PPC_REL16 relocations. I don't see any of these relocs. The .plt section is marked ALLOC CODE WRITE in non-SecurePLT and ALLOC WRITE in SecurePLT. Is the ABI incorrect or is Binutils not following it? Is there any possibility of a chimera: an executable compiled using Secure PLT linking to libraries which use the old style PLT? Or vice-versa? I'm assuming that this cannot happen. I can modify BFD to record whether the .plt section in the executable was marked CODE or not, create an new OSABI sniffer to identify a new GDB_OSABI_LINUX_SECUREPLT ABI variant, and then write the variants of find_solib_trampoline_target(), etc., which are needed to recognize the PLT stubs and glink code. I'm open to suggestions about a different approach. Is there something which I may have overlooked? -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077