From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9935 invoked by alias); 8 Feb 2006 21:40:24 -0000 Received: (qmail 9924 invoked by uid 22791); 8 Feb 2006 21:40:23 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 08 Feb 2006 21:40:22 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k18LdYSH010670; Wed, 8 Feb 2006 22:39:34 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k18LdX2k014341; Wed, 8 Feb 2006 22:39:33 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k18LdXig008477; Wed, 8 Feb 2006 22:39:33 +0100 (CET) Date: Wed, 08 Feb 2006 21:40:00 -0000 Message-Id: <200602082139.k18LdXig008477@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: aoliva@redhat.com CC: gdb-patches@sources.redhat.com, cagney@redhat.com In-reply-to: (message from Alexandre Oliva on Wed, 08 Feb 2006 03:18:01 -0200) Subject: Re: cope with varying prelink base addresses References: Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00189.txt.bz2 > From: Alexandre Oliva > Date: Wed, 08 Feb 2006 03:18:01 -0200 > > --=-=-= > > If you take a core file created on a box whose libraries have been > prelinked with random base addresses and try to use it for debugging > on another box that has the very same binaries, but prelinked with a > different base address, gdb will get all confused. > > That's because the load_addr of the prelinked binaries will be > whatever difference there was between the base address selected by > prelink and the base address used at run time by the dynamic loader. > If everything is prelinked successfully, the load addresses will all > be zero. > > So when gdb reads the binary prelinked with a different base address, > and applies to it the load address read from the core file, it won't > get the correct address if the prelinked binary on the debugging host > got a different address. > > This is arguably a change in the binary, so debugging is not expected > to work anyway, but it definitely is surprising, especially when > prelink is enabled by default. This would render core files useless > across different hosts. > > This patch gets gdb to try to recognize the situation in which a > binary got prelinked but is otherwise unchanged, and figure out the > difference between the base addresses at core-generating host and at > the debugging host. > > The only piece of information available for this that I could find was > the address of the dynamic table in the dynamic loader data > structures. The heuristics I used was to check whether the dynamic > table address changed but remained at the same position within a > page. If so, I assume the difference is caused by prelinking, and > then I adjust the load_addr that gdb is going to use for that binary. > Otherwise, it will face the same problems you're expected to face when > debugging a core file using a different binary. > > I'd appreciate if whoever reviews this would pay particular attention > to the gdb testcase; it's the first time I write one, and I could use > some guidance to make sure I'm not making undeserved assumptions. > It's bad enough that I have to use compile- and run-time flags that > will likely only work with GCC and GNU ld, and that the test requires > the prelink program to be in the PATH; I hope I'm coping well with > cases in which the flags are not accepted or prelink is not in place. > > Comments? Ok to install? Tested on amd64-linux-gnu. This code is very fragile, and defenitely should be tested on more than a single platform. In the past, we've seen that not every OS interprets the l_addr field of `struct link_map'. And MIPS targets have a history of doing things differently even for the same OS. Basically the two interpretations are: a. l_addr is the absolute address at which the shared object is loaded. b. l_addr is the relative address used to relocate the shared object. The confusion arises because many platforms traditionally "pre-link" at address 0, and then the difference doesn't matter. I'm afraid my knowledge of pre-linking isn't detailed enough to check whether this has any impact on the pre-linking problem. The word "heuristic" makes me a bit nervous. It seems to me that the dynamic linker should be able to provide the necessary information. Perhaps you should raise the issue with the glibc developers, to see what they can do? Mark