| 1 |
On Tue, 01 Aug 2006 19:57:36 +0200 |
| 2 |
pageexec@××××××××.hu wrote: |
| 3 |
|
| 4 |
> On 31 Jul 2006 at 17:41, Ned Ludd wrote: |
| 5 |
> > I think the major problem we are facing here is how to cleanly |
| 6 |
> > upgrade from 3.x to 4.x. symbol names have changed. And using the |
| 7 |
> > stub/aliases method Peter used in uClibc svn allows the __guard to |
| 8 |
> > be overwritten. |
| 9 |
> |
| 10 |
> what do you mean by that? i thought the guard was in writable memory |
| 11 |
> anyway... |
| 12 |
> |
| 13 |
> > Flags are missing etc. |
| 14 |
> |
| 15 |
> what flags? |
| 16 |
|
| 17 |
I think solar's referring to -fno-stack-protector-all. Not too worried |
| 18 |
about that myself, I think we can hide the change in semantics in |
| 19 |
flag-o-matic.eclass - actual ebuild use of -fno-stack-protector-all is |
| 20 |
rare. |
| 21 |
|
| 22 |
> > Upstream also destroyed the value of the handler. |
| 23 |
> |
| 24 |
> in what sense? i thought that 4.x also had a reporting function... |
| 25 |
|
| 26 |
It's that gcc-4.x doesn't pass the caller information (function name |
| 27 |
and line number) to _stack_chk_fail. |
| 28 |
|
| 29 |
I've been thinking that a PaX-style register, stack and perhaps map dump |
| 30 |
might be a good idea for development environments at least. |
| 31 |
|
| 32 |
-- |
| 33 |
Kevin F. Quinn |
Archives