This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM Compilers: refer external symbols from elf

Note: This was originally posted on 18th April 2011 at http://forums.arm.com

HI guys,



is it possible to compile a source file where the external symbols should be referred in the elf (elf for whole build) by ARM compiler/Linker.

we use compilers :ADS120 ,RVCT3.1,RVCT4.1

Scenario :

Build consist of all the source, we make build by integrating  this source file/changes and we compile whole build. so if there is any compilation/link error with integrated source file/changes we will able to know after whole build is compiled .
i want to optimize this process,by compiling only changed files before integrating in the whole build ,where external symbols should be referred in elf (generated for whole build(previous  successful build)). Once it compiled successfully i can integrated in build and compile.so by this process i will be able to resolve the errors in very less time.

Thanks for reading the post.
  • Note: This was originally posted on 18th April 2011 at http://forums.arm.com


    Sure - compile each source file to an object file, and then link all of the object files to form the executable. Objects can both import and export symbols, so that should be no problem. For each file changed you should have to recreate a single object and then just rerun the link step.

    Thanks  for the replay isogen..
    do you mean that while linking each object file's unresolved symbols would be referred from elf..

    if so,it would be great if u share the linking command/any tutorial where i can refer it.

  • Note: This was originally posted on 20th April 2011 at http://forums.arm.com


    For each of the source file compiles call "armcc" with "-c" option; this tells the compiler to compile the file but not to link it, so it can have symbols it exports and symbols which is it missing and will need in future from other objects. The output from each invocation of the tools will be an ELF object.


    armcc foo.c -c -o foo.o
    armcc bar.c -c -o bar.o
    ... etc ...


    Once you have built all of your objects link them with "armlink" to get the ELF executable:


    armlink foo.o bar.o -o example.exe





    Thanks for the replay isogen


    if we give linking command as "armlink  foo.o bar.o Build.elf -o Build_new.elf"  it will work..?

    actually the unresolved symbols of foo.o and bar.o are present in elf(Build.elf) not in other objects.

    i want know only whether it is able to resolve all the external symbols..?  if not then output the  symbol's whose definition is unavailable with its respective object file from where it is refered.


    Thanks



  • Note: This was originally posted on 20th April 2011 at http://forums.arm.com


    Once you have complied things to an executable no symbolic information is exported, so an ELF executable cannot be an input to a link step.

    You original question was around trying to avoid recompiling everything  if only a few files have changed - build tools like GNU Make will only rebuild what has changed, and reuse the old output objects if the file has not changed. I'd suggest investigating that type of Build tool - it does exactly what you are trying to do ...

    Iso


    Iso.. i am so sorry if i confuse you....

    let me  try to explain clearly   the question again...

    Our Builds system is like for every src changes we keep a separate builds(compiled src code ) in filers i.e if we have changes to fix x,y,z bugs respectively. we sync whole src code and integrate x bug fixes then make a build (Build 1)like wise we do a separate builds for y(Build 2),z(Build 3).so we sync whole src code and compile the whole  for only few file changes.

    In above when we integrate fixes, these changes might have some  compilation/linking issue,if so we can know after few hrs(i.e after whole build src got synced and tried to compile).So, to reduce the time.. i thought of 

    compile only those changes with -c option without integrating in the build and compiling whole build.

    in the above process we can know only about compilation errors(i.e syntactical errors ) whether they are present or not. But for linking errors,i need to resolve the all external symbols referred by  obj file.


    so , my Question is whether we have any option/way  in linking to tell linker to fetch external symbols referred by obj file from elf of build(which has all the symbols defined  bye each source file in build).

    Thanks for the reading my post patiently :)




  • Note: This was originally posted on 23rd April 2011 at http://forums.arm.com

    Thanks Iso..  and [color=#222222][font=Arial, Verdana, Tahoma, sans-serif][size=4]Marcus.. [/size][/font][/color]
    [color=#222222][font=Arial, Verdana, Tahoma, sans-serif][size=4]
    [/size][/font][/color]
    [color=#222222][font=Arial, Verdana, Tahoma, sans-serif][size=4]can i do in this way...[/size][/font][/color]
    [color=#222222][font=Arial, Verdana, Tahoma, sans-serif][size=4]
    [/size][/font][/color]
    [color=#222222][font=Arial, Verdana, Tahoma, sans-serif][size=4]i will list all the symbols in elf image (by using Readelf tools)and i will direct its out put to some symbol.txt.In the same way i will list all symbols present in obj file.now i will check this symbols [/size][/font][/color]
    [size=4]whether they are present in symbols.txt[/size]
    [size=4]
    [/size]
    [size=4]From above way  if i found all the symbols then i can assume that src file compiles fine when i integrate in the build or else it will fail with unresolved external symbol.[/size]
    [size=4]
    [/size]
    [size=4]Thanks for Reading my post..:)[/size]
  • Note: This was originally posted on 22nd April 2011 at http://forums.arm.com

    >> But for linking errors,i need to resolve the all external symbols referred by obj file.

    Assuming you know what objects have changed (the ones you just recompiled), the ones which haven't (all the others which you built last time), I don't see why you can't just do a normal link step. So in general I still stick by my last point that you need to fix your build system ...

  • Note: This was originally posted on 18th April 2011 at http://forums.arm.com

    Sure - compile each source file to an object file, and then link all of the object files to form the executable. Objects can both import and export symbols, so that should be no problem. For each file changed you should have to recreate a single object and then just rerun the link step.
  • Note: This was originally posted on 18th April 2011 at http://forums.arm.com

    For each of the source file compiles call "armcc" with "-c" option; this tells the compiler to compile the file but not to link it, so it can have symbols it exports and symbols which is it missing and will need in future from other objects. The output from each invocation of the tools will be an ELF object.


    armcc foo.c -c -o foo.o
    armcc bar.c -c -o bar.o
    ... etc ...


    Once you have built all of your objects link them with "armlink" to get the ELF executable:


    armlink foo.o bar.o -o example.exe
  • Note: This was originally posted on 20th April 2011 at http://forums.arm.com

    Once you have complied things to an executable no symbolic information is exported, so an ELF executable cannot be an input to a link step.

    You original question was around trying to avoid recompiling everything  if only a few files have changed - build tools like GNU Make will only rebuild what has changed, and reuse the old output objects if the file has not changed. I'd suggest investigating that type of Build tool - it does exactly what you are trying to do ...

    Iso
  • Note: This was originally posted on 21st April 2011 at http://forums.arm.com

    So basically what you are looking for is a way to link an object to an image in a way that all symbol references in this new object replace existing symbol references of inside the image. Even if this were technically possible (which I doubt for the general case anyway), I don't think it would actually save time. The linker would have to decompose the image and reassign all relocations. What about removed sections, which might suddenly be referenced from the new objects?

    Since you  have to support a number of tool versions, partial linking doesn't appear to be an option either.

    Good luck
    Marcus