From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20369 invoked by alias); 30 Apr 2004 00:27:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20307 invoked from network); 30 Apr 2004 00:27:32 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 30 Apr 2004 00:27:32 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i3U0RQwR015159 for ; Thu, 29 Apr 2004 17:27:26 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Thu, 29 Apr 2004 17:27:31 -0700 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i3U0RTNn022405; Thu, 29 Apr 2004 17:27:29 -0700 (PDT) In-Reply-To: <40911AA8.9080106@gnu.org> References: <9B827536-9972-11D8-9EA7-000A9569836A@apple.com> <40911AA8.9080106@gnu.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <299FE029-9A3D-11D8-AC77-000A9569836A@apple.com> Content-Transfer-Encoding: 7bit Cc: Joel Brobecker , gdb-patches@sources.redhat.com From: Jason Molenda Subject: Re: Question about blockframe.c:inside_main_func() Date: Fri, 30 Apr 2004 00:27:00 -0000 To: Andrew Cagney X-SW-Source: 2004-04/txt/msg00699.txt.bz2 On Apr 29, 2004, at 8:09 AM, Andrew Cagney wrote: > However, I think the entire function's contents are bogus. It should > look like: > > if (symtab_find_function_range_by_name (main_name (), &low_pc, > &high_pc)) > return pc in [low_pc, high_pc); > else > return 0; > > so that the logic is pushed back into the symbol table (an obvious > thing for lookup_function_range_by_name to do is implement a > look-aside cache). Just so I'm clear -- this is a function that doesn't exist right now, right? We have at least one similar address range cache in the Apple gdb to keep track of some oft-referenced ObjC dispatch functions (which could be subsumed by a symtab_find_function_range_by_name() type function). > (they need to be killed off anyway as PIE breaks the assumption that > the values are constant across function invocations). I don't really know what PIE means - I thought it meant that the executable was built PIC and would be loaded at an arbitrary address on each run. How could a function shift locations while the inferior is executing? >> [*] We have something called "ZeroLink" where the main executable -- >> the symfile_objfile -- is a tiny stub that demand-loads each object >> file (formatted like a shared library) as functions/global variables >> in those .o's are referenced. So in our case, the symfile_objfile >> doesn't contain main at all; hence me looking into this function and >> scratching my head about why it's re-searching for this function >> every time... > > you might want to look at PIE. It's a pretty different thing, if I'm not mistaken. PIE is about loading your executable at an arbitrary address, isn't it? ZeroLink is about avoiding the static link editor stage in development. You build your .o's (and they're built as little shared libraries), and you run the ZL stub program in place of your main application. The ZL stub program loads at the usual 0x0 address, like a normal program. It builds up a list of available functions in all the .o's and pulls them in on-demand. It's entirely a development-time speed deal. I thought PIE was more about security, putting the executable in different places so hax0rs can't hardcode where interesting functions et al are located. Maybe I misunderstood what PIE encompasses? Thanks, Jason