Hi Albert,
On 11/10/2012 12:25 PM, Albert ARIBAUD wrote:
Hi Gerlando,
On Tue, 30 Oct 2012 12:08:01 +0100, Gerlando Falauto
<gerlando.fala...@keymile.com> wrote:
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?
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
