This is the mail archive of the gcc-patches@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: rs6000_flag_pic


>>>>> Alan Modra writes:

Alan> OK, thanks for the info.  Compiling a few quick examples (from
Alan> ld/testsuite/ld-selective/*.cc) shows that with my patch, the vtables
Alan> indeed go from being in rw sections to ro sections.  However, the
Alan> vtables just have a bunch of R_PPC64_ADDR64 relocs, which won't be
Alan> dynamic.  Hmm, I suppose the problem only shows up when linking
Alan> a -fno-pic app against shared libs.  Do you have testcases?

	The problem originally was uncovered in K42, a research operating
system being developed at IBM that uses the same ABI as PPC64 Linux.  The
OS is written in C++.  We were finding that application text was being
mapped private when it should have been shared, causing performance
degradation.  This was traced back to the section into which GCC was
emitting vtables and I got a message from my colleagues that GCC was doing
something inefficient.

	I do not remember the example, I would need to go back and find
it.  vtables can include pointers to functions from shared libraries which
may have different addresses in different processes.  Scenarios I can
imagine include different instances of the same application using
different shared libraries (different shared object search paths or
LDPRELOAD), or the same shared library loaded at different addresses in
different processes, but I believe the original problem was more common
than those examples.  Once one has a reloc in the text section, the
section must be mapped private.

David


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