This is the mail archive of the
mailing list for the GCC project.
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
- From: Chris Johns <chrisj at rtems dot org>
- To: Manuel López-Ibáñez <lopezibanez at gmail dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>, Joel Sherrill <joel dot sherrill at oarcorp dot com>, Sandra Loosemore <sandra at codesourcery dot com>, Jakub Jelinek <jakub at redhat dot com>, David Malcolm <dmalcolm at redhat dot com>, Jeff Prothero <jprother at altera dot com>
- Date: Tue, 03 Mar 2015 19:41:43 +1100
- Subject: Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
- Authentication-results: sourceware.org; auth=none
- References: <CAESRpQApz7M63-ETnT8bsHyCtqU4UhLfjjT4a0Y8BbJRU0Q=vw at mail dot gmail dot com>
On 28/02/2015 9:12 am, Manuel López-Ibáñez wrote:
On 02/19/15 14:56, Chris Johns wrote:
My main concern is not knowing the trap has been added to the code. If I
could build an application and audit it somehow then I can manage it. We
have a similar issue with the possible use of FP registers being used in
general code (ISR save/restore trade off).
Can the ELF be annotated in some GCC specific way that makes it to the
final executable to flag this is happening ? We can then create tools to
audit the executables.
Simply ignore me if I'm misunderstanding the issue: Couldn't GCC
generate, instead of a trap, a call to a noinline noreturn cold weak
function __gcc_is_a_trap that by default calls the trap? Then, audit
tools can inspect the code and see if such a function call appears and
even override it with something else.
Yes it could and this is a nice idea.
Chris, wouldn't that be enough for your purposes?
I think it does because we can scan an executable for the call locations
and audit them.