[U-Boot] analyze/change assembly code

[Gerlando Falauto]

On 11/20/2012 02:26 PM, Marek Vasut wrote:
> 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?

ELDK, correct.

>> 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.

OK, but... what's that to do with my question?
*WAAAAIIIT*!!!
You mean you suspect my problem might be due to a broken GCC?
No, that was not the case. In the end there was something wrong with 
some CPU settings, so the same code executed tons of times was failing 
every once in a while. Generated assembly was not wrong, though being 
able to refactor it might have been useful in order to identify what 
code pattern was likely to fail (e.g. arithmetics on a register read 
from memory, unless adding a NOP after the ALU operation -- weirdly 
enough, *after* as opposed to *between load and arithmetics*! ).

Anyway, any ideas on how to inspect/manipulate assembly (yes, also for 
catching compiler bugs)?

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

Best regards,
Gerlando