Hi All,
As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the following codes, if we compile it by -O2, it will crash with "segment fault", if we just comment " if(unifi_debug >= level) {", all will be ok. If we don't compile it by -O2, all will be ok too.
#include <stdlib.h> #include <stdio.h> #include <stdarg.h>
#define DEBUG_BUFFER_SIZE 80 int unifi_debug = 5;
void unifi_trace(void* ospriv, int level, const char *fmt, ...) { static char s[DEBUG_BUFFER_SIZE]; va_list args; unsigned int len;
if(unifi_debug >= level) { va_start(args, fmt); len = vsnprintf(&(s)[0], (DEBUG_BUFFER_SIZE), fmt, args);
va_end(args); if (len >= DEBUG_BUFFER_SIZE) { (s)[DEBUG_BUFFER_SIZE - 2] = '\n'; (s)[DEBUG_BUFFER_SIZE - 1] = 0; }
printf("%s", s); } }
int main(void) { char *prog = "/usr/sbin/unififw"; unifi_trace(NULL, 1, "start %s\n", prog); return 0; }
Thanks Barry
On 27/04/11 10:08, Barry Song wrote:
Hi All,
As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the following codes, if we compile it by -O2, it will crash with "segment fault", if we just comment " if(unifi_debug>= level) {", all will be ok. If we don't compile it by -O2, all will be ok too.
Sorry, are you saying that the compiler crashes, or are you saying that the output binary crashes at runtime?
Andrew
2011/4/27 Andrew Stubbs andrew.stubbs@linaro.org:
On 27/04/11 10:08, Barry Song wrote:
Hi All,
As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the following codes, if we compile it by -O2, it will crash with "segment fault", if we just comment " if(unifi_debug>= level) {", all will be ok. If we don't compile it by -O2, all will be ok too.
Sorry, are you saying that the compiler crashes, or are you saying that the output binary crashes at runtime?
the target binary got crash while running on armv7 board, not gcc :-)
Andrew
2011/4/27 Andrew Stubbs andrew.stubbs@linaro.org:
On 27/04/11 10:23, Barry Song wrote:
the target binary got crash while running on armv7 board, not gcc :-)
I suspect I know what the problem is here.
Can you try again with -fno-shrink-wrap, please?
i guess it is related with this bug:
https://bugs.launchpad.net/gcc-linaro/+bug/771675
Andrew
On Wed, Apr 27, 2011 at 9:52 PM, Barry Song 21cnbao@gmail.com wrote:
2011/4/27 Andrew Stubbs andrew.stubbs@linaro.org:
On 27/04/11 10:23, Barry Song wrote:
the target binary got crash while running on armv7 board, not gcc :-)
I suspect I know what the problem is here.
Can you try again with -fno-shrink-wrap, please?
i guess it is related with this bug:
Hi Barry. Thank you for the bug report. I've confirmed this with gcc-linaro-4.5-2011.04-0 on ARM and logged LP: #772085 at: https://bugs.launchpad.net/gcc-linaro/+bug/772085
Please subscribe to the bug if you'd like to be updated with any progress.
As you say, the generated code is incorrect and clobbers r3 before use:
unifi_trace: @ args = 4, pretend = 8, frame = 8 @ frame_needed = 0, uses_anonymous_args = 1 movw r3, #:lower16:.LANCHOR0 movt r3, #:upper16:.LANCHOR0 ldr r3, [r3, #0] cmp r3, r1 bge .L6 bx lr .L6: push {r2, r3}
This only occurs if you add the -fshrink-wrap option. It does not occur at -O1, -O2, or -O3. The fault does not occur in Linaro GCC 4.6, gcc-4.5.2, or gcc-4.6.0. I suggest you update to Linaro GCC 4.5-2011.04 which fixes a number of other shrink wrap bugs and also disables it by default.
I've set it to medium priority as while it is bad-code, the fault only occurs if you add -fshrink-wrap. This fault will be fixed before shrink wrapping is turned back on by default.
This is probably the same fault as LP: #736081 and LP: #771675.
-- Michael
linaro-toolchain@lists.linaro.org