This is the mail archive of the mailing list for the binutils 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]

Resolve symbols for object files in link script

Hello, everyone:

It seems to me that the order LD resolves symbols is:

(1) the object files listed in the command line
(2) the object files listed in the link script

If I recalled correctly, each archive is opened only once, unless
otherwise specified. If libc.a, libm.a, libgcc,a are opened in the
step (1), the symbol in those archived won't be resolved in step (2).
After observing the verbose output of LD, my terrible solution is in
addition to list the object files in the SECTIONS in the link script,
aslo list them again in a GROUP command.

The link script:

 /* Listing libc.a libm.a and libgcc.a are required. */
 GROUP(foo.o bar.o .../* a lot of object files here */ ... libc.a
libm.a libgcc.a)

   .a : { foo.o } > ram
   .b : { bar.o } > ram

The problem is when the number of object file grows, it becomes a pain
in ass to maintain the link script (it has already been), and the
linking time is increased by the GROUP command too. I'm porting a
large software and I have to manually put the object files into
different sections. GCC __attribute__ is not feasible, because there
are thousands of functions in each object file.

Better approach, anyone, please?

Tzu-Chien Chiu - SMedia Technology Corp.

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