[U-Boot] analyze/change assembly code

[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)

What do you mean it didn't behave properly???? How's that even possible?
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