"Steve M. Gehlbach" steve@nexpath.com writes:
more summary: the problem is limited to those cases where someone wants to use SERIAL_POST.
Seems pretty fixable.
Any more ideas on this? I chased it around a bit but there sure seems to be a symbol conflict on _start.
Okay I see the point, these are separate pieces of code. Looks like the post is inlined unless SERIAL_POST is set, at which point console_tx_al is called in crt0. The address of console_tx_al is not fixed at the point c_start.o is linked. Not easy to fix, maybe someone else has some ideas.
O.k. I believe I see what is going on.
When CONFIG_COMPRESS was introduced intel_chip_post simply yielded a post code. So it was safe to call it both from both binaries.
Then someone modified intel_chip_post to change it's behavior when SERIAL_POST is called to output the post code to the serial port.
That is so bad, and broken.
It breaks the compile of c_start.S because it attempts to call code in another binary. It potentially breaks all callers of intel_chip_post because the set of registers stomped has gone from %al to: %eax %esp %edx
Extremely unexpected.
If we want post codes to show up on the serial port even from the assembly code we need to introduce another macro, and carefully replace the users of intel_chip_post. Rather than change the calling conventions of intel_chip_post.
So for the short term the proper fix is to revert the recent change to intel_chip_post....
Eric