by GreggChandler » Tue May 09, 2017 9:42 pm
My guess, and it is only a guess, is that the .bss segment is causing your problem. You can examine your link map, and determine which code, data, and uninitialized variables are being loaded in the various parts of the address space. If the change was correctly made, and it appears to have been in the file you supplied, then the code should have been correctly moved to the external segment. The data should have been moved as well. That is the first step. The next step is to determine which segment(s) is/are causing your overflow. I don't know if objective C generates CTOR's, DTOR's, etc. (Adding " .bss" after the ".data" specification for your LLK_LIB_WR specification would help determine if .bss is the problem.)
Although I have written objective C code, it has been a while, and I never examined the generated object code too closely. (It was for the iPad/iPhone, and the Apple ecosystem kept me too far from the actual code.) I remember strings with object stuff in them. Loading them in external memory would be important. Hopefully they are part of .rodata.
I tried moving my .bss segment to external memory, and my C++ program wouldn't run. I believe that is because C++ may have assumed that the uninitialized data segment was actually initialized to zero. (What is the irony of that? In the old days, it really was uninitialized!) I assume objective C would be similar.
Examining the link map, one can see where objects and symbols are defined to bracket the segment--presumably so that it can be initialized. (Look for __bss_start.) If this is the case, then the next thing to do would be modify the run-time initialization code to support initialization of the external bss segment. I looked for the crt* source on my micro sever, and haven't found it yet. I am sure that the source is on GitHub, but I haven't found it there yet either. Without examining the source, this is all speculation.
e-size -A myfile.elf will produce a good summary of program components, their load addresses, and their sizes. It would be interesting to see what it reports.
Another option would be to move all .bss data to the external segment, however, I suspect that would be too slow. I suspect splitting the .bss is your best bet. I'll keep looking for the CRT* source code.
Yet another option is that your main program, as distinct from your library, is generating the overflow. The tools should reveal the real cause.
Interesting commentary on this topic, and something else to try.