From: Jason Molenda <jmolenda@apple.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: Joel Brobecker <brobecker@gnat.com>, gdb-patches@sources.redhat.com
Subject: Re: Question about blockframe.c:inside_main_func()
Date: Fri, 30 Apr 2004 00:27:00 -0000 [thread overview]
Message-ID: <299FE029-9A3D-11D8-AC77-000A9569836A@apple.com> (raw)
In-Reply-To: <40911AA8.9080106@gnu.org>
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
next prev parent reply other threads:[~2004-04-30 0:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-29 0:17 Jason Molenda
2004-04-29 1:02 ` Joel Brobecker
2004-04-29 1:50 ` Jason Molenda
2004-04-29 15:09 ` Andrew Cagney
2004-04-30 0:27 ` Jason Molenda [this message]
2004-04-30 0:49 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=299FE029-9A3D-11D8-AC77-000A9569836A@apple.com \
--to=jmolenda@apple.com \
--cc=brobecker@gnat.com \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox