[U-Boot] analyze/change assembly code

[Marek Vasut <marex@denx.de>]

Dear Gerlando Falauto,

> On 11/20/2012 09:54 AM, Marek Vasut wrote:
> > Dear Gerlando Falauto,
> > 
> >> Hi all,
> >> 
> >> we recently to had face some nasty issues, where for some reason two
> >> (functionally identical) versions of some code behave very differently.
> >> Namely, one version works and the other doesn't always work.
> >> It was clear from the beginning this was because of HW- (or compiler-)
> >> related issues.
> >> I thought it would then be useful to have a peek at what the compiler is
> >> doing behind the scenes, and possibly make some simple changes to the
> >> code. For instance, inserting some nops here and there, or reordering
> >> some instructions, may help in tracking down these different behaviors.
> >> 
> >> I know the easiest way to LOOK at the file is simply to use objdump to
> >> disassemble an .o file. In the end I somehow managed to tamper with the
> >> makefiles so to get what I wanted for a given file, by adding a fake new
> >> ".s" target with the recipe to build it, and having the .o file depend
> >> on a ".S" file (which would be a manual/changed copy of the generated
> >> ".s" file) instead of the original ".c" file.
> >> This is however not linear and nice at all. So I was wondering whether
> >> there already is a well-established way of having the make process
> >> create (and keep) assembly files which can be then manually changed.
> >> 
> >> Does my question make any sense at all? Any ideas?
> > 
> > What compiler do you use? The Linaro one didn't behave properly for
> > example.
> 
> powerpc-linux-gcc (GCC) 4.6.4 20120303 (prerelease)
> arm-linux-gnueabi-gcc (GCC) 4.6.4 20120303 (prerelease)

Where did you get this from, ELDK or elsewhere?

> What do you mean it didn't behave properly???? How's that even possible?

The Linaro toolchain had broken libgcc and u-boot pulls in components from this 
libgcc ... thus the breakage.

> A compiler which doesn't translate to assembly and from assembly to
> binary is by definition a _BROKEN_ compiler, so I strongly doubt that...
> Or maybe I got you wrong?
> 
> Best regards,
> Gerlando

Best regards,
Marek Vasut