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: Cannot export all symbols from a module

I am creating a program in assembler, using several modules. The Assembler manual states that using the EXPORT directive, without any arguments, exports all symbols from the module. When I use this construct, I get flooded with undefined symbol errors. I have to go back and individually export each symbol in order to get a clean assembly and link. Is this an artifact of using an evaluation license, or is something screwy going on. I tried EXPORT * and it really yelled at me. Having to individually export all of the variable names and equates would be a major hurt. Thanks.

Parents
  • My first Pascal program was just a single file. It grew and grew and grew and I scrolled and I scrolled and I scrolled. That editor refused to make the file larger than 64kB in which case I just had to split the code into multiple source files.

    For some strange reason, I liked having multiple files where each file contained functions with a specific purpose, and where I didn't had to scroll so much. So I decided to continue to use multiple source files even when the editor wasn't the limiting factor - I have never seen a reason to change my mind.

    Modern tools can handle truly huge source files, and even a full recompile after each change is normally quite quick. But it just is no fun to try to maintain such a project.

    But as noted earlier - when splitting code into modules, not all of the code in the modules needs to be accessible from the outside. Each module should have a public interface and have everything else hidden.

    A huge number of global variables? The question then is if not much of these global variables should have been combined as individual fields in structures or maybe C++ classes. Or if some of the data should have been completely hidden inside different modules, with only some accessor functions available to operate on the actual data values.

    But the global name space should really not be too littered with symbols.

Reply
  • My first Pascal program was just a single file. It grew and grew and grew and I scrolled and I scrolled and I scrolled. That editor refused to make the file larger than 64kB in which case I just had to split the code into multiple source files.

    For some strange reason, I liked having multiple files where each file contained functions with a specific purpose, and where I didn't had to scroll so much. So I decided to continue to use multiple source files even when the editor wasn't the limiting factor - I have never seen a reason to change my mind.

    Modern tools can handle truly huge source files, and even a full recompile after each change is normally quite quick. But it just is no fun to try to maintain such a project.

    But as noted earlier - when splitting code into modules, not all of the code in the modules needs to be accessible from the outside. Each module should have a public interface and have everything else hidden.

    A huge number of global variables? The question then is if not much of these global variables should have been combined as individual fields in structures or maybe C++ classes. Or if some of the data should have been completely hidden inside different modules, with only some accessor functions available to operate on the actual data values.

    But the global name space should really not be too littered with symbols.

Children
No data