>> The perf built to run on the host needs to use arm-eabi-objdump from >> the toolchain so that it can analyse data recorded on Android. This >> patch is targeting this scenario, not the previous one. In this case, >> the CROSS_COMPILE option would be different than arm-eabi- so using >> $(CROSS_COMPILE)objdump would be wrong. objdump should be overridden >> when running make since there is no connection between the toolchain >> used here and the path for objdump. I am always overriding objdump >> when calling make, so I did not catch this. >> >> I think that I should change DEFAULT_OBJDUMP_PATH=objdump in the >> Makefile to handle the first scenario. I'll also explain this in the >> commit message so that it is more clear and make the same change for >> the addr2line patch. >> >> What do you think? > > I think the right thing to do is finding a correct objdump at runtime in > some way. Why do you want to make it compile-time configurable? >
The correct objdump path can be detected at runtime by setting the toolchain path. But since the name is arm-eabi-objdump and not objdump, it does not know to use it instead. The only way (I can think of) to change objdump at runtime would be to use the --objdump option for perf annotate (and provide a similar option for addr2line). The problem with this approach is that the user has to be aware that perf annotate uses the objdump tool and that he has to use the cross-compiler version instead. Since the user will have perf compiled for host as part of his Android tree, he will expect it to work without these further changes from his part. The path for objdump can be set in the Android Makefile at compile time so that the user doesn't need to be aware of it. If compiling directly from the kernel tree, the advantage is not that obvious. The user would still have to specify the name for objdump in the command line when running make. But I think this is still a better user experience compared to having to set this every time when using perf annotate. Thanks, Irina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
