Hi Larry,
On 03/10/12 10:45, Larry Baker wrote:
I don't recall off-hand what you will see by forcing a trap 7.
But it is easy to check, try a strait trap 7 call in a test program.
I hacked the .s file to force a trap #7. That looked like a normal program
exit -- no messages on the console, nothing in dmesg or /var/log/messages.
I'll look at the kernel trap handler and see what trap #7 means.
I use trap #7 because the conditional trap instructions use trap vector #7.
Issuing a trap #7 will just cause the kernel to send a SIGILL signal to the
process. If it is not caugth it will probably cause process termination.
(All software traps, except 0, do this on ColdFire).
I am not familiar with gcc's stack checking options and code.
Does it just check the value of sp at function entry and exit?
Or is it more elaborate than that?
Stack checking is at function entry only. So, stack variables declared at the
start of a code block within a function are not checked.
Ok, better than nothing I guess.
overflow: overflow:
> move.l __stack_start@GOT(%a5),%a0
> lea (404,%a0),%a0
> cmp.l %sp,%a0
> bls.s .+4
> trap #7
It would be pretty easy to just add a whole bunch of debug trace in
the kernel when you get this - just for debugging purposes of course.
Probably makes no sense for a user space process to catch the SIGILL
in this case. You are out of stack and drastic action is needed.
[snip]
Be mindful that on older ColdFire Cores, that only had a single A7,
then the CPU will be pushing the exception frame onto the user
space stack (so an extra 8 bytes).
In addition to implementing the "conditional trap" instruction patterns for non-68020
processors, I fixed the code to always check before pushing any registers on the stack and before
allocating space on the stack for automatic variables. I didn't pick a "minimum" stack
that must remain. For example, the null function void junk{} generates:
#NO_APP
.file"junk.c"
.text
.align2
.globljunk
.typejunk, @function
junk:
move.l __stack_start@GOT(%a5),%a0
addq.l #4,%a0
cmp.l %sp,%a0
bls.s .+4
trap #7
rts
.sizejunk, .-junk
.ident"GCC: (GNU) 4.6.1 20120905 (prerelease)"
.section.note.GNU-stack,"",@progbits
It only checks that 4 bytes are available. (To account for a frame pointer?
That's my guess. I changed 4 to INCOMING_FRAME_SP_OFFSET in the stack checking
code. There is not always a frame pointer, though, like in this case.) Maybe
some minimum value would be a good idea, just to account for the single A7 you
describe -- so some minimum trap or O/S call could be handled. It's easy
enough to modify the stack checking code. Not sure, though, what flags tell
the compiler there is only one A7.
There is no need to tell the compiler, it doesn't really care. That is
only something that the Operating System cares about. User processes are
completely oblivious to the implementation of exception frames - and
that is what you want.
On your example junk function above, if you are running that on a
ColdFire with a single A7 then when you hit "trap #7" the CPU will
push the 8 bytes of the exception frame onto the current user stack,
and then switch to supervisor mode (ie enter the kernel). On most
other CPU types, and ColdFires that have separate supervisor and user
A7 registers, the CPU will switch to supervisor mode, switch to using
the kernels A7 and then push the 8 bytes of exception frame.
You would have to be unlucky to be 8 bytes short, that is why I said
to just be mindfull of this happening.
Regards
Greg
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
