Re: __stack_start for ColdFire uClinux

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:     [email protected]
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
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev