RE: Locating library modules during link

["Gregory W. Ratcliff" <gratcliff at peco2 dot com>]

Stan,

Can't the list of input section also be file specific?  as such you could
make a section called  sysa.o (.sysasection) ?

Then you can choose to include or not include the file.  Does this get you
what you need?

Greg Ratcliff

-----Original Message-----
From: crossgcc-owner@sources.redhat.com
[mailto:crossgcc-owner@sources.redhat.com]On Behalf Of Stan Katz
Sent: Friday, October 11, 2002 3:24 PM
To: binutils@sources.redhat.com; crossgcc@sources.redhat.com
Subject: Locating library modules during link


Hi,

I am working on an embedded application using the GCC tools and I have a
question about using the linker.
The hardware I am using (Hitachi SH2) has fast internal Flash and Ram and I
want to be able to use the linker
to put the code that is time critical (hardware drivers, etc.( into this
internal area. During the initial development
I have been specifying the module names (object files) in the SECTIONS
command in the linker script and that
has been working.

The problem is that for production we will be generating several systems
containing different combinations of the
drivers, and we plan to add drivers as the new hardware is developed. The
original plan was to place all the drivers
in a library archive and to let the linker select the needed drivers. This
is also now working.

The problem is combining the 2 requirements. Any files explicitly listed in
the SECTIONS command behave as
if they were specified in the file list (as the documentation does say). If
the file does not exist in the current
directory or as specified by a vpath command in the makefile, the build
fails because the linker cannot find the
module. This is usually the case since the driver library has its own build
area. If the linker is given the location
of the object files then the link succeeds, but all drivers mentioned in the
link script are included, even when they
are not referenced and the library archive is never used.

As I see it there are 2 options
1. To generate a link script for each possible combination or drivers, and
forget about the library.
2. To find a way to get the linker to resolve the references in the library
and control the memory region.

Can anyone on either the CrossGCC or binutils lists suggest a way to achieve
option 2 or find another alternative
to achieve the result I need. I have tried using the section attribute to
place the executable code from the library a
separate segment (.libtext) and the data in .libdata, and then using
"*(.libtext) *(.text)" to locate the code in the
internal Flash, followed by any additional executable code. Unfortunately
however, the linker seems to allocate
the library data last (which is as I expected) and by the time any code from
the library is included the internal
Flash is already full with other code and the .libtext data ends up after
the .text.

Any other ideas out there, or am I going to have to look into extending the
linker ?

Stan Katz

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com