Bugzilla Bug 135265

Bug to track C++ problems with the SSP we add to gcc-3.x

The SSP implementation we add to gcc-3.x does not like data declared elsewhere
than in the initial declaration section of a function, which is legal in C++
but not in C.  Definitely the issue on 133301, likely also for 115237 and
probably 136891 and 101776.

Would backing off on the -all option for CXX be ideal?

I don't think so, as -all will just reduce the likelihood of it being hit.  By
how much is difficult to say as it depends on how often sweep-able variables
occur in the same functions as the declarations that trigger the bug.

Regarding the dep'd bugs that are Qt specific:

The users have noted that the breakage occurs in 3.3.6 but NOT in 3.3.4.  I
viewed the source for two of the bugs in question and the source hasn't changed
between these versions (ie, the creation of a stack variable within a subblock
of a function exists exactly the same in both versions).

What else could be the cause then?  Could some kind of bad cflags possibly be
the culprit?  Perhaps the buildsystem mechanisms changed between 3.3.4 and
3.3.6 and we just haven't caught it yet.

(In reply to comment #3)
> The users have noted that the breakage occurs in 3.3.6 but NOT in 3.3.4.

Yeah, I noticed that.  The difficulty is in knowing how the issue is triggered.
 I'm inclined to believe it is down to context; perhaps the data passed into
the function is different in size for example.  Changes elsewhere in the code
could cause the fault to become visible.  Note that the stack smash only occurs
if the canary is overwritten - perhaps whatever data is being written doesn't
quite reach the canary.

SSP does play significantly with the stack layout; it duplicates parameters and
re-orders locally declared data to arrange to have any buffers located after
the scalar data, so that buffer overflows won't corrupt the scalar data and are
more likely to hit the canary.

It should be detectable by comparing the asm output from the function with the
declaration in each place; I'm building some stuff at the moment to
investigate.

re 133301 - seems SSP isn't causing the problem, just highlighting it (see
comments there).

I think it'll be worth investigating the other bugs further, see if they're the
same.

all these bugs remind on one that solar gave me some 2-3 years ago, a few lines
of c++ that crashed when compiled with SSP. i had spent a whole day of
debugging what turned out to be a function prologue code generation bug in SSP
and these bugs look very similar to that, maybe an angle to pursue... the next
question is then, how are you going to fix it? that old bug was never addressed
by Etoh (even though we gave him all the details) and i doubt he'd touch SSP
these days again.

i think bug 133092 belongs here as well.

I think bind in bug 158664 also suffer some kind of strange interaction with
SSP.

*** Bug 192564 has been marked as a duplicate of this bug. ***

https://hardened.gentooexperimental.org/secure/

Dw.

GCC 4.3.4 is stable on hardened.  All tracked bugs closed in one form or
another.  GCC 3.4.x is frozen/not being worked on. Closing as WONTFIX.