analyze/change assembly code
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?
Thank you,
Gerlando
Hi Gerlando,
Quoted 22 lines · 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.
Quoted 1 line
Does my question make any sense at all? Any ideas?
Add -save-temps to the gcc arguments? Watch out for parallel build issues, though.
Amicalement,
Signature · 1 line
Albert.
Hi Albert,
Quoted 27 lines · Albert ARIBAUD
Hi Gerlando,
Quoted 22 lines · 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.
Quoted 4 lines
Quoted 1 line
Does my question make any sense at all? Any ideas?
Add -save-temps to the gcc arguments? Watch out for parallel build issues, though.
I tried, and it partly does the trick, in that the .s file is created and kept afterwards. Manually changing the .s file though doesn't help, as it gets overwritten by successive invocations...
Thanks anyway,
Gerlando
Dear Gerlando Falauto,
Quoted 22 lines
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.
Quoted 1 line
Does my question make any sense at all? Any ideas?
What compiler do you use? The Linaro one didn't behave properly for example.
Best regards,
Marek Vasut
Quoted 24 lines · Marek Vasut
Dear Gerlando Falauto,
Quoted 22 lines
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.
Quoted 3 lines
Quoted 1 line
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
Dear Gerlando Falauto,
Quoted 25 lines · Marek Vasut
Quoted 24 lines
Dear Gerlando Falauto,
Quoted 22 lines
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.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
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?
Quoted 1 line
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.
Quoted 6 lines
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
Hi Marek, Gerlando,
Quoted 4 lines · Marek Vasut
Quoted 1 line
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.
Marek: I don't know if that is supposed to be a case where Linaro is supposed to fail, but FWIW, a versatileqemu build performed with the Linaro ARM gcc version from Ubuntu 12.04 would fail to run whereas built with the Linaro ARM gcc from Ubuntu 12.10 -- 4.7.2 (Ubuntu/Linaro 4.7.2-1ubuntu1) -- it does work. So maybe Linaro fixed their act.
Quoted 2 lines
Quoted 2 lines
A compiler which doesn't translate to assembly and from assembly to binary is by definition a _BROKEN_ compiler
Gerlando, you may have to revise this definition: I think LLVM does not necessarily translate through assembly language, at least, not through the target's assembly language, and LLVM assembly language may count as 'intermediate representation' rather than true 'assembly language'.
Amicalement,
Signature · 1 line
Albert.
Quoted 29 lines · Marek Vasut
Dear Gerlando Falauto,
Quoted 27 lines · Marek Vasut
Quoted 26 lines
Dear Gerlando Falauto,
Quoted 23 lines
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?
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 1 line
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)?
Quoted 9 lines
Quoted 6 lines
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,
GerlandoBest regards,
Marek Vasut
Best regards,
Gerlando