This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: linking possibilities
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Subject: Re: linking possibilities
- From: Rafael Rodríguez Velilla <rrv at tid dot es>
- Date: Tue, 12 Jun 2001 09:45:07 +0200
- Organization: Telefónica I+D
- References: <200106112359.QAA21714@kankakee.wrs.com>
> > What does gcc when I specify the -fPIC switch?
> I'll assume the question is:
> What does gcc do when I specify the -fPIC switch?
Correct, that was the question. It has been a long time since I learnt
English.
> The answer is, it will produce position independent code. Exactly how
> it does this, or even if it will do this, is platform specific.
My platform is a custom platform with an embedded ARM.
> > Where are these kind of things documented (which sections are
> > created, where is the different data located ....)?
>
> Documenting internal choices made by the compiler is somewhat bad, as
> it tends to constrain future changes to the compiler. Our tendency is
> to not document such things. If you want a document, you will find
> one from the vendor of the OS that originally designed the position
> independent code or possibly from the abi body that designed the abi.
So the processor independent code is also dependent on the OS? I use just
arm-elf-gcc (this should be OS independent).
Any suggestion on where can I find the information of the PIC for the ARM?
> > All the work that I'm doing is basen on experiments, but I'm not
> > sure if it will work that way always.
> I don't know what you need to know. I don't know how you want to use
> the information you have collected. The as if rule of compilation
> allows us to do just about anything we want, and if you expect us to
> to just about anything in particular you will be burned. The things
> that we will do are specified in the various language standards and
> the various abi standards. If you are relying upon something that
> isn't in such a document, then you're probably creating non-portable
> code.
I'm sure that someone before me has used gcc to compile a "shared library"
for an embedded system (stored in a ROM or a FLASH), and surely there's a
neater way to use this library than what I'm doing (I have made a perl
script that extracts the symbols of the executable and prepares a linker
script using that information).
The information I need to know is, for example, what is the section
.rel.got that gets generated when I use a global variable and compile with
-fPIC switch?
The only information that I have about -fPIC is that it generates
processor independent code, no rule of use, no hints... Only that it doesn't
support processor independent data (and I have not learnt that from the
documentation).
It's a pity because it seems to me that gcc (and related tools) are the
most powerful I have ever seen, and surely it does much more than I can
imagine but the information is a little hidden.
Surely gcc has a standard way to do what I want.
Thank you for your attention. I hope I'm not bothering, if so, please let
me know.
--
Rafael Rodríguez Velilla rrv@tid.es
Telefónica I+D http://www.tid.es
Telf: +34 - 91 337 4270