Re: linking possibilities

Re: linking possibilities

[mike stump]

> Date: Fri, 08 Jun 2001 18:00:36 +0200
> From: Rafael =?iso-8859-1?Q?Rodr=EDguez?= Velilla <rrv@tid.es>
> To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>

> What I would want to do is to download the threads individually, not
> the whole operating system.

> Can I compile somehow an application using the information of the
> locations of the routines of another one (not an obect file but an
> executable)?

Yes, I believe you can, see the ld documentation.  This is a binutils
(ld) question by the way, doesn't have much to do with gcc.

.TP
.BI "\-R " "filename"
Read symbol names and their addresses from \c
.I filename\c
\&, but do not
relocate it or include it in the output.  This allows your output file
to refer symbolically to absolute locations of memory defined in other
programs.

> Is there a way to include in an executable all the functions of a
> library even if they are not referenced in the application (in order
> to have them in case any of the new downloaded threads needs them)?

Again, this is a binutils (ld) question, I am not sure.  The option
--whole-archive looks promising.

.TP
.B \-\-whole\-archive
For each archive mentioned on the command line after the
.B \-\-whole\-archive
option, include every object file in the archive in the link, rather
than searching the archive for the required object files.  This is
normally used to turn an archive file into a shared library, forcing
every object to be included in the resulting shared library.

Re: linking possibilities

[Rafael Rodríguez Velilla]

> > Can I compile somehow an application using the information of the
> > locations of the routines of another one (not an obect file but an
> > executable)?
>
> Yes, I believe you can, see the ld documentation.  This is a binutils
> (ld) question by the way, doesn't have much to do with gcc.

  Then let's try with a more gcc related issue...


 What does gcc when I specify the -fPIC switch?
 Where are these kind of things documented (which sections are created,
where is the different data located ....)? All the work that I'm doing is
basen on experiments, but I'm not sure if it will work that way always.

Re: linking possibilities

[mike stump]

> From: "Zack Weinberg" <zackw@stanford.edu>
> Date: Tue, 12 Jun 2001 01:54:33 -0700
> To: Rafael Rodr?guez Velilla <rrv@tid.es>
> Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>

> You need the ELF spec and the relevant parts of the ABI.  Start at
> < http://www.sco.com/developer/gabi/ >.

> Date: Tue, 12 Jun 2001 12:47:18 +0100
> From: Richard Earnshaw <rearnsha@arm.com>

> http://www.arm.com/armwww.ns4/img/12-Technical+Specs-ARM+ELF+Specification+PDF/$File/ARMELFA08.pdf

> This should probably be linked off of < http://gcc.gnu.org/readings.html >.

Done.  I put them next to the PowerPC abi stuff near the bottom.

Re: linking possibilities

[Zack Weinberg]

On Tue, Jun 12, 2001 at 12:45:43PM +0100, Richard Earnshaw wrote:
> > Aha.  You need the ELF spec and the relevant parts of the ABI.  Start
> > at < http://www.sco.com/developer/gabi/ >.  You'll want the ARM
> > processor-specific supplement as well.  That is probably on arm.com
> > somewhere, but that server seems to be down right now.
> 
> Not for me it isn't.
> 
> http://www.arm.com/armwww.ns4/img/12-Technical+Specs-ARM+ELF+Specification+
> PDF/$File/ARMELFA08.pdf?OpenElement

Must have been a transient problem, I can get there too, now.

-- 
zw    Network yo kakumei suru tame ni means your ass is mine, motherfucker.
      	-- Wednesday

Re: linking possibilities

[Rafael Rodríguez Velilla]

Richard Earnshaw wrote:

> > Aha.  You need the ELF spec and the relevant parts of the ABI.  Start
> > at < http://www.sco.com/developer/gabi/ >.  You'll want the ARM
> > processor-specific supplement as well.  That is probably on arm.com
> > somewhere, but that server seems to be down right now.
>
> Not for me it isn't.

  I can access the web pages correctly (I have seen faster servers but it
seems to work).

Re: linking possibilities

[Rafael Rodríguez Velilla]

> Aha.  You need the ELF spec and the relevant parts of the ABI.  Start
> at < http://www.sco.com/developer/gabi/ >.  You'll want the ARM
> processor-specific supplement as well.  That is probably on arm.com
> somewhere, but that server seems to be down right now.
>
> This should probably be linked off of < http://gcc.gnu.org/readings.html >.

   With this I have reading for a while...
  Once more, thank you all.

Re: linking possibilities

[Richard Earnshaw]

Let's try that again with line-wrapping turned off.

> Aha.  You need the ELF spec and the relevant parts of the ABI.  Start
> at < http://www.sco.com/developer/gabi/ >.  You'll want the ARM
> processor-specific supplement as well.  That is probably on arm.com
> somewhere, but that server seems to be down right now.

Not for me it isn't.

http://www.arm.com/armwww.ns4/img/12-Technical+Specs-ARM+ELF+Specification+PDF/$File/ARMELFA08.pdf?OpenElement

Re: linking possibilities

[Richard Earnshaw]

> Aha.  You need the ELF spec and the relevant parts of the ABI.  Start
> at < http://www.sco.com/developer/gabi/ >.  You'll want the ARM
> processor-specific supplement as well.  That is probably on arm.com
> somewhere, but that server seems to be down right now.

Not for me it isn't.

http://www.arm.com/armwww.ns4/img/12-Technical+Specs-ARM+ELF+Specification+
PDF/$File/ARMELFA08.pdf?OpenElement

Re: linking possibilities

[Zack Weinberg]

On Tue, Jun 12, 2001 at 09:45:07AM +0200, Rafael Rodr?guez Velilla wrote:
> 
>   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?

Aha.  You need the ELF spec and the relevant parts of the ABI.  Start
at < http://www.sco.com/developer/gabi/ >.  You'll want the ARM
processor-specific supplement as well.  That is probably on arm.com
somewhere, but that server seems to be down right now.

This should probably be linked off of < http://gcc.gnu.org/readings.html >.

-- 
zw              But the voices in my head are what keeps me sane.
                	-- Shweta Narayan

Re: linking possibilities

[Rafael Rodríguez Velilla]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2883 bytes --]

> > 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

Re: linking possibilities

[mike stump]

> Date: Mon, 11 Jun 2001 09:54:03 +0200
> From: Rafael =?iso-8859-1?Q?Rodr=EDguez?= Velilla <rrv@tid.es>
> To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>

> > > Can I compile somehow an application using the information of the
> > > locations of the routines of another one (not an obect file but an
> > > executable)?
> >
> > Yes, I believe you can, see the ld documentation.  This is a binutils
> > (ld) question by the way, doesn't have much to do with gcc.

> Then let's try with a more gcc related issue...

> 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?

The answer is, it will produce position independent code.  Exactly how
it does this, or even if it will do this, is platform specific.

> 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.

> 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.

linking possibilities

[Rafael Rodríguez Velilla]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

  I'm trying to do a thing that I don't know if gcc is capable of doing
so I use this list to ask if it does.
  I'm programmig for ARM with arm-elf-gcc.
  I use eCos (Embedded Configurable Operating System) which is capable
of running threads.
  The normal way of working with eCos is first compile in a library all
eCos functionality, then prepare an application that defines some
threads (their functions and memory) and puts them to run, then link it
against the eCos library and download it to the target platform.

  What I would want to do is to download the threads individually, not
the whole operating system. I have thought that I could do this if I
could download first all the image of the operating system, linked with
an application capable of receiving an object file and make it to run.

  The problem is that I'd want that the new thread use the functions of
the OS. I have the prototipes, I have the elf version of the downloaded
image in my PC and I think that it would be enough to link the thread
code knowing where on memory are allocated the different functions (I
can see this information with arm-elf-nm).

  The final questions are:
  Can I compile somehow an application using the information of the
locations of the routines of another one (not an obect file but an
executable)?
  Is there a way to include in an executable all the functions of a
library even if they are not referenced in the application (in order to
have them in case any of the new downloaded threads needs them)?






--
Rafael Rodríguez Velilla        rrv@tid.es
Telefónica I+D          http://www.tid.es
Telf: +34 - 91 337 4270