gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] gcl and function descriptors


From: Camm Maguire
Subject: [Gcl-devel] gcl and function descriptors
Date: Mon, 16 Jun 2014 09:36:39 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Greetings, and thanks so much for asking!

I had already done some work on gcc110, so things are already looking
pretty good.

Perhaps you might help me pin down an ABI question pertaining to
function descriptors.  I first became acquainted with these via ia64,
and then hppa.  While this obviously affects the linker, there was a
more subtle fix required for gcl as well -- one could not store *global*
function addresses in .data, dump the image with unexec, and reexecute
later and count on the saved address still being good, even when the
addresses were in .text.  Somehow, having int foo(int x) {return x;} int
main() {save_and_dump(&foo)} ended up capturing not the address of the
descriptor, as the abi seems to indicate should be the case, but the
underlying address, which was not guaranteed to be constant across
reexecution.  If foo was static, no problem, likewise if calls were made
through pointers.  This bug is very hard to trigger, usually requiring
moving a saved image to a different machine, but this happens all the
time in distributing gcl build programs in Debian, for example.  

We have a work around, defining all saved .text functions as static,
which can be enabled at compile time, and we have it on now for ppc64.
But I was curious if this was really necessary, as it is cumbersome.

Take care,

David Gosselin <address@hidden> writes:

> Hi Camm,
> How're things working-out for you?  Is there anything I can do to help?
> Thanks,
> Dave
>
-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]