[GSoC - x86_64] Pre-merge issues (at -O2 optimization level) and WIP review

[Amaan Cheval]

Hi!

In the process of cleaning my work up, I've run into an odd problem
which only shows up when I set the optimization level to -O2. At -O0,
it's perfectly fine.

The issue is that somehow execution ends up at address 0x0.

This likely happens due to a _CPU_Context_switch, where the rsp is set
to a corrupted value, leading to a corrupt (i.e. 0) return address at
the end of the context switch.

What's curious is that this corruption _seems_ to occur in
_ISR_Handler's call to _Thread_Dispatch, by somehow messing the value
of rsp up - I honestly don't know this for sure because gdb says one
thing (i.e. that rsp = 0), but setting up some code (cmpq $0, rsp) to
check this seems to say rsp is non-zero, at least.

This is an odd heisenbug I'd like to investigate for sure - I just
thought I'd shoot this email out because:

- If I can't figure it out tomorrow, soon, I'll just drop it so I can
create more logical commits to send as patches upstream (thereby
leaving -O0 upstream, at least temporarily)

- If anyone's seen an odd stack corruption like this, or has any
advice on debugging it, could you let me know? I suspect something
like interrupting tasks which ought not to be interrupted (perhaps I
forgot to implement some kind of "CPU_ISR_Disable") - is there
anything you can think of of that sort?

Also, here's a Github PR like last time with all the work (just for
the overall changes, not the specific commits!). I'd appreciate a
quick review if anyone could - sorry about sending this out over the
weekend! I've had a surprising share of Heisenbugs with QEMU in the
past week.

https://github.com/AmaanC/rtems-gsoc18/pull/3/files