Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Oct 2012 21:40:22 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Difference between -O2 and -g

On Fri, Oct 26, 2012 at 09:31:56AM +0800, Brian Wang wrote:
> Hello all,
> 
> I am experiencing a rather strange problem...
> 
> I have an oldish kdrive/Xfbdev that works on my ARM device with
> CodeSourcery toolchains.
> Now, I tried it with musl (0.9.6 and the recent git master branch as well).
> First it failed to find the screen and refused to start.  After some naive
> attempts with printf without success, I recompiled it with -g and no
> -Ox with the hope that gdbserver
> would help pin point the problem.  However, with only -g, it runs!

-g should have absolutely no effect on code behavior, but it sounds
like your two setups are "-O2" and "-O0 -g" (where the -O0 is the
default). If that's the case, when code behaves differently with
different optimization levels, the cause is almost surely undefined
behavior. Another possibility is a bug in musl (possibly an
ARM-specific bug), but if you didn't recompile musl with different
options, I doubt that's the cause.

One very simple way to get a picture of what's going on in a program
is to run it under strace. Try saving strace logs for both the working
version and the broken version and comparing them either manually or
with the diff utility (although the latter may be difficult unless you
filter out the addresses and other contnets that will naturally
differ, so it might be easier to visually inspect). If you don't
already have an strace built for your target, I think Aboriginal Linux
has static binaries you can use.

If you're having trouble analyzing the results I'd be happy to help
you.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.