This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Gcl-devel] Re: function addresses and ld.so


Greetings!

"Zack Weinberg" <zack@codesourcery.com> writes:

> Camm Maguire <camm@enhanced.com> writes:
> 
> > 2) What if some other variable in a different file defines a different
> >    pointer and assigns its value to this pointer, e.g. double
> >    (*ptr1_sqrt)(double)=ptr_sqrt; , and saves this pointer into an
> >    unexeced .data section?  Don't I have the same problem?  (In a
> >    separate posting, I've clarified that my problem is not in
> >    referring to symbols in external shared libs such as sqrt, but in
> >    referring to addresses in my .text section from variables unexeced
> >    into the .data section.
> 
> My expectation is that that should just work.  As such, your problem
> is not what I thought it was, and my advice is probably no good.
> 
> Function descriptors can't be avoided on the platforms that use them,
> nor should you even try.  Are you perhaps casting between object and
> function pointers?
> 

I don't think so.  My current understanding is that the behavior I've
described is limited to ia64, arising from the implementation of
function descriptors there realized at runtime via mmap.  I'm
wondering if there is a workaround in GCL pending any possible fixes
to ia64 ldso short of static linking.

Thanks again,

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]