"Ronald G. Minnich" rminnich@lanl.gov writes:
I am going to continue on this but it will be slow, I have a lot going on.
The basic problem as I see it is that there is a little more magic in the build process than it can stand, and specific platforms are breaking.
In c_start.S and the constructed crt0.S there is a symbol called _start. Same name.
Yes but in different binaries. c_start.S and crt0.S should never be linked together.
There is one binary that is all of the code before ram is initialized. And another that is code after ram is initialized.
There are also, in these files, a set of symbols that on some builds are needed for that build. So we need the .o from both files in some builds. But the conflicting _start symbols are causing trouble.
How? What links them together?
Simple attempts to change the name of the start symbol (e.g. change _start in crt0.S to _machine_reset_start) lead to a host of other undefined symbols, since once the _start is undefined, that file is not pulled in and the symbols in that file are not resolved.
I would rather not get into 'weak' symbols in assembly code files.
Anyway, if anyone gets a chance to look at this and has some ideas ... let me know. But we need to fix this situation.
I need to see what the real problem that is linking together two different binaries before I can give a good suggestion.
Eric