order of modules to linker

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

order of modules to linker

georg.chambert@telia.com
Hi,
I have an issue, which i have "solved" in that it now works, but Im curious why.
 
I linked a load module where I had a library of my own (.a) and a number of
object modules.
 
I used external in the file containing main, however outside main, to get the linker to include
two ISRs that were located in the .a and one of the .o files
 
I also used directives for the Atmega8 to use internal EEPROM, EEMEM directive for declaration, and
the other constructs needed for accessing the EEPROM.
 
NOW: first time I linked my .a file was last in the list of modules;  the resulting load module didnt work.
 
I checked out the .lst usinng listing option for the .elf file; and saw a strange ting, on the position of the vector for
vector_11, there instead was written some strange address (very high) and some eeprom-information......
(vector_11 is in the m8 the address for the UART RX interrupt, which I use, and the ISR is loceted in the .a file)
 
Now I got some back-of-the-head hunch, so I re-arranged so that the .a was first in the link-list, and sure enough
the vector_11 was now a fine address to the ISR, and the load-module work (what I can see so far)
 
WHAT WAS THAT, is my question (I usuallly want to understand whats happening, otherwise things tend
to come back in some other shape and bite u)
 
/georg

_______________________________________________
AVR-chat mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-chat
Reply | Threaded
Open this post in threaded view
|

Re: order of modules to linker

Erik Christiansen-2
On 06.01.18 15:21, georg chambert wrote:
> Now I got some back-of-the-head hunch, so I re-arranged so that the .a
> was first in the link-list, and sure enough the vector_11 was now a
> fine address to the ISR, and the load-module work (what I can see so
> far)
>
> WHAT WAS THAT, is my question (I usuallly want to understand whats
> happening, otherwise things tend to come back in some other shape and
> bite u)

Too true. But your example runs contrary to my experience, which is that
it is necessary to place a library (.a) _after_ all the object files
which need it, because the linker reads each file only once. Thus a .o
file on the command line after a needed .a will fail to have its
externals satisfied by the library which has already whizzed past, and
is gone.

Crux: Only the parts of a library which are required for unsatisfied
externals are pulled in by the linker. So place the libraries last, with
libraries needing other libraries preceding those which don't.

If there are reciprocal or cyclical dependencies, then list them thus:
"-( archives -)", and ld will search them repeatedly until no new
undefined references  are created.

Erik

_______________________________________________
AVR-chat mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-chat
Reply | Threaded
Open this post in threaded view
|

Postscript: Re: order of modules to linker

Erik Christiansen-2
In reply to this post by georg.chambert@telia.com
On 06.01.18 15:21, georg chambert wrote:
> I used external in the file containing main, however outside main, to
> get the linker to include two ISRs that were located in the .a and one
> of the .o files

While I don't use 'C' to provide my vector table or ISRs, ISTR that the
practice there has long been to provide weak jumps to __bad_interrupt,
to be overwritten by the strong symbols provided with your ISRs.

That works if your ISRs are in an object file, but there is nothing to
pull them in from an archive, AFAICT without seeing your code. What was
done to provide a need to pull in the ISR from the library?

Erik

_______________________________________________
AVR-chat mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-chat
Reply | Threaded
Open this post in threaded view
|

Re: order of modules to linker

georg.chambert@telia.com
In reply to this post by Erik Christiansen-2
Hello Erik, thanks for suggestions,

however, now I have discovered that there still is som problem;
I had thought that the linker would complain if it couldnt do its jobb, but
evidently that is not the case

The obvious error in the .lst file for vector is gone, but when running,
some functionality is lost.
What I have done is that I have merged a functionality into my main code,
where each
of the two codes in their respective test-beds have worked fine.
One of the this were picking up stored information from internal EEPROM,
which  was
working in the main code, But where the "vector confusion" in the first
linkage, with library last,
gave strange references to the eeprom handling routines, on the vecor
position, was present.
And which went away seemingly ok, when moving lib up, but evidently still
not ok, since now
in the combined code the fetch from internal EEPROM fails.

The constructs of suspition is my use of "extern" directive, which I use in
main file (not in void main module though)
to get the linker to pick up the two ISRs I use (one for uart RX, which
works in the load module, and one for
timer/counter1, which I  think work, but cannot be sure actually, at least
it doesnt crash) This counter and the ISR are
essential in the new feature added.

----- Original Message -----
From: "Erik Christiansen" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, January 07, 2018 2:52 AM
Subject: Re: [avr-chat] order of modules to linker


> On 06.01.18 15:21, georg chambert wrote:
>> Now I got some back-of-the-head hunch, so I re-arranged so that the .a
>> was first in the link-list, and sure enough the vector_11 was now a
>> fine address to the ISR, and the load-module work (what I can see so
>> far)
>>
>> WHAT WAS THAT, is my question (I usuallly want to understand whats
>> happening, otherwise things tend to come back in some other shape and
>> bite u)
>
> Too true. But your example runs contrary to my experience, which is that
> it is necessary to place a library (.a) _after_ all the object files
> which need it, because the linker reads each file only once. Thus a .o
> file on the command line after a needed .a will fail to have its
> externals satisfied by the library which has already whizzed past, and
> is gone.
>
> Crux: Only the parts of a library which are required for unsatisfied
> externals are pulled in by the linker. So place the libraries last, with
> libraries needing other libraries preceding those which don't.
>
> If there are reciprocal or cyclical dependencies, then list them thus:
> "-( archives -)", and ld will search them repeatedly until no new
> undefined references  are created.
>
> Erik
>
> _______________________________________________
> AVR-chat mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avr-chat 


_______________________________________________
AVR-chat mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-chat