From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14675 invoked by alias); 16 Apr 2010 19:20:51 -0000 Received: (qmail 14664 invoked by uid 22791); 16 Apr 2010 19:20:50 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hqemgate03.nvidia.com (HELO hqemgate03.nvidia.com) (216.228.121.140) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Apr 2010 19:20:44 +0000 Received: from hqnvupgp03.nvidia.com (Not Verified[172.17.102.18]) by hqemgate03.nvidia.com id ; Fri, 16 Apr 2010 12:22:00 -0700 Received: from hqemfe03.nvidia.com ([172.17.108.22]) by hqnvupgp03.nvidia.com (PGP Universal service); Fri, 16 Apr 2010 12:20:43 -0700 X-PGP-Universal: processed; by hqnvupgp03.nvidia.com on Fri, 16 Apr 2010 12:20:43 -0700 Received: from cvpn.wur-de.14-105.nvidia.com ([172.17.108.22]) by hqemfe03.nvidia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Apr 2010 12:20:41 -0700 Date: Fri, 16 Apr 2010 19:20:00 -0000 From: Simo Melenius To: gdb@sourceware.org Subject: Program image not relocated if it's a solib already loaded by dlopen() Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-NVConfidentiality: public MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: 2010-04/txt/msg00051.txt.bz2 I have an interesting corner case I would like to discuss in depth. Please point me to some other mailing list such as gdb-patches if this is too developer-heavy. Let's go: Quick question: is the use case described below even supposed to work? I have an arm-eabi-linux platform where I use gdb and gdbserver. I have a program ``foo'' that uses dlopen() to load ``libfoo.so'' which contains a function symbol ``foobar''. The program ``foo'' will first load the library, wait for some time to let me attach gdbserver, and will then call that function. Assume I'm developing ``libfoo.so'' and am not particularly interested in ``foo'' itself. So, I start ``foo'', attach gdbserver to it, and invoke gdb on the host platform as follows: $ arm-eabi-gdb libfoo.so Then I appropriately use ``target remote'' to connect to the gdbserver and issue: (gdb) break foobar Breakpoint 1 at 0x3a0: file libfoo.c, line 7. (gdb) continue Continuing. Warning: Cannot insert breakpoint 1. Error accessing memory address 0x3a0: Input/output error. Based on the low breakpoint pc address, gdb uses the section offsets directly from ``libfoo.so'' without ever relocating them against the base address where ``libfoo.so'' was actually loaded. I can verify this by disassembling the contents of ``libfoo.so'' and looking at the offset where gdb wanted to install the breakpoint. It seems that in some cases gdb treats the program argument a bit differently than other images. In the above case, the corresponding "struct objfile" for the program image seems to be constructed before gdb connects to the inferior and probes its solib list. When it does that, the objfile for ``libfoo.so'' isn't updated appropriately and the non-relocated offsets remain in effect. However, if I invoke gdb as: $ arm-eabi-gdb foo everything works. Then gdb just finds ``libfoo.so'' in the inferior's so_list and reads its live address as usual. It also works if I attach gdbserver to ``foo'' _before_ ``libfoo.so'' is loaded: gdb correctly notices that ``libfoo.so'' isn't loaded yet and the breakpoint is just made a pending one and is resolved when dlopen() is called and the library is loaded. While this can be worked around, should it work the first way, too? If it should work, I would appreciate some help in constructing a patch. I know what's wrong but I haven't got a clear picture of what would be the right way to fix this. kind regards, Simo -- Simo Melenius, NVIDIA Corporation, smelenius@nvidia.com, http://eu.nvidia.com