From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21254 invoked by alias); 30 Mar 2006 22:42:00 -0000 Received: (qmail 21246 invoked by uid 22791); 30 Mar 2006 22:41:58 -0000 X-Spam-Check-By: sourceware.org Received: from e1.ny.us.ibm.com (HELO e1.ny.us.ibm.com) (32.97.182.141) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Mar 2006 22:41:55 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k2UMfqFI001657 for ; Thu, 30 Mar 2006 17:41:52 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2UMfqHP236168 for ; Thu, 30 Mar 2006 17:41:52 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2UMfq5C009554 for ; Thu, 30 Mar 2006 17:41:52 -0500 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2UMfp8q009503 for ; Thu, 30 Mar 2006 17:41:52 -0500 Subject: Strange stepping behaviour with PPC 64 and secure PLTs From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: gdb@sources.redhat.com Content-Type: text/plain Date: Fri, 31 Mar 2006 06:55:00 -0000 Message-Id: <1143758781.21920.464.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00226.txt.bz2 On a system with secure PLTs for 32-bit apps, when 'next'ing through a simple 32-bit hello world program, GDB does not execute 'printf' and then stop. Instead, it seems to get lost in the 'lazy' invocation of the dynamic loader. Here is a transcript: pgilliam:~/gdb/tree-head> build/gdb/gdb hello32 GNU gdb 6.4.50.20060330-cvs ... This GDB was configured as "powerpc64-unknown-linux-gnu"...Using host libthread_db library "/lib64/power4/libthread_db.so.1". (gdb) start Breakpoint 1 at 0x100004a4: file hello-simp.c, line 6. Starting program: /home/pgilliam/gdb/tree-head/hello32 main () at hello-simp.c:6 6 printf("Hello, world\n"); (gdb) bt #0 main () at hello-simp.c:6 (gdb) n 0x10000810 in call___do_global_ctors_aux () (gdb) bt #0 0x10000810 in call___do_global_ctors_aux () #1 0x0fea97f0 in generic_start_main () from /lib/power4/libc.so.6 #2 0x0fea9a4c in __libc_start_main () from /lib/power4/libc.so.6 #3 0x00000000 in ?? () (gdb) n Single stepping until exit from function call___do_global_ctors_aux, which has no line number information. 0xf7ff5110 in _dl_runtime_resolve () from /lib/ld.so.1 (gdb) bt #0 0xf7ff5110 in _dl_runtime_resolve () from /lib/ld.so.1 #1 0x100004b0 in main () at hello-simp.c:6 (gdb) n Single stepping until exit from function _dl_runtime_resolve, which has no line number information. 0x0fef4f70 in puts () from /lib/power4/libc.so.6 (gdb) bt #0 0x0fef4f70 in puts () from /lib/power4/libc.so.6 #1 0x100004b0 in main () at hello-simp.c:6 (gdb) n Single stepping until exit from function puts, which has no line number information. ---- apparent hang here (really single stepping through 'puts') --- If I "finish" out of 'call___do_global_ctors_aux', things don't get back on track. Instead, GDB "finish"s out of 'main': pgilliam:~/gdb/tree-head> build/gdb/gdb hello32 GNU gdb 6.4.50.20060330-cvs ... This GDB was configured as "powerpc64-unknown-linux-gnu"...Using host libthread_db library "/lib64/power4/libthread_db.so.1". (gdb) start Breakpoint 1 at 0x100004a4: file hello-simp.c, line 6. Starting program: /home/pgilliam/gdb/tree-head/hello32 main () at hello-simp.c:6 6 printf("Hello, world\n"); (gdb) bt #0 main () at hello-simp.c:6 (gdb) n 0x10000810 in call___do_global_ctors_aux () (gdb) bt #0 0x10000810 in call___do_global_ctors_aux () #1 0x0fea97f0 in generic_start_main () from /lib/power4/libc.so.6 #2 0x0fea9a4c in __libc_start_main () from /lib/power4/libc.so.6 #3 0x00000000 in ?? () (gdb) finish Run till exit from #0 0x10000810 in call___do_global_ctors_aux () Hello, world 0x0fea97f0 in generic_start_main () from /lib/power4/libc.so.6 (gdb) q If I do a "next" instead of a finish when stopped at call___do_global_ctors_aux, then the stack looks right again and a "finish" will get things back on track. pgilliam@elm3b18:~/gdb/tree-head> build/gdb/gdb hello32 GNU gdb 6.4.50.20060330-cvs ... This GDB was configured as "powerpc64-unknown-linux-gnu"...Using host libthread_db library "/lib64/power4/libthread_db.so.1". (gdb) start Breakpoint 1 at 0x100004a4: file hello-simp.c, line 6. Starting program: /home/pgilliam/gdb/tree-head/hello32 main () at hello-simp.c:6 6 printf("Hello, world\n"); (gdb) bt #0 main () at hello-simp.c:6 (gdb) n 0x10000810 in call___do_global_ctors_aux () (gdb) bt #0 0x10000810 in call___do_global_ctors_aux () #1 0x0fea97f0 in generic_start_main () from /lib/power4/libc.so.6 #2 0x0fea9a4c in __libc_start_main () from /lib/power4/libc.so.6 #3 0x00000000 in ?? () (gdb) n Single stepping until exit from function call___do_global_ctors_aux, which has no line number information. 0xf7ff5110 in _dl_runtime_resolve () from /lib/ld.so.1 (gdb) bt #0 0xf7ff5110 in _dl_runtime_resolve () from /lib/ld.so.1 #1 0x100004b0 in main () at hello-simp.c:6 (gdb) finish Run till exit from #0 0xf7ff5110 in _dl_runtime_resolve () from /lib/ld.so.1 Hello, world main () at hello-simp.c:7 7 } (gdb) bt #0 main () at hello-simp.c:7 (gdb) c Continuing. Program exited with code 015. (gdb) q Note: in the old 32-bit PowerPC ABI the value of a PLT entry was an executable instruction. This was deemed security risk so in the new ABI, PLT entries are pointer to routines, much like they are for 64-bit apps. In GDB for PowerPC, finding the real address of the function is done by 'bfd_get_synthetic_symtab' when the elf file is loaded. If this routine was not working correctly due to a change in the ABI, would that explain what I am seeing? -=# Paul #=-