[U-Boot] [PATCH] arc: introduce "mdbtrick" target

MetaWare debugger doesn't support PIE (position-independent executable) so the only way to load U-Boot in MDB is to fake it by: 1. Reset PIE flag in ELF header 2. Strip all debug information from elf
Even though it could be done manually but having this automated way is very convenient. User may build U-Boot that will be loaded on target via MDB saying "make mdbtrick".
Signed-off-by: Alexey Brodkin abrodkin@synopsys.com Cc: Tom Rini trini@ti.com --- arch/arc/Makefile | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
diff --git a/arch/arc/Makefile b/arch/arc/Makefile index de25cc9..03ea6db 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -6,3 +6,18 @@ head-y := arch/arc/cpu/$(CPU)/start.o
libs-y += arch/arc/cpu/$(CPU)/ libs-y += arch/arc/lib/ + +# MetaWare debugger doesn't support PIE (position-independent executable) +# so the only way to load U-Boot in MDB is to fake it by: +# 1. Reset PIE flag in ELF header +# 2. Strip all debug information from elf +ifdef CONFIG_SYS_LITTLE_ENDIAN + EXEC_TYPE_OFFSET=16 +else + EXEC_TYPE_OFFSET=17 +endif + +mdbtrick: u-boot + $(Q)printf '\x02' | dd of=u-boot bs=1 seek=$(EXEC_TYPE_OFFSET) count=1 \ + conv=notrunc &> /dev/null + $(Q)$(CROSS_COMPILE)strip -g u-boot

Dear Alexey,
In message 1419587516-30541-1-git-send-email-abrodkin@synopsys.com you wrote:
MetaWare debugger doesn't support PIE (position-independent executable) so the only way to load U-Boot in MDB is to fake it by:
- Reset PIE flag in ELF header
- Strip all debug information from elf
Even though it could be done manually but having this automated way is very convenient. User may build U-Boot that will be loaded on target via MDB saying "make mdbtrick".
I wonder if such manipulation helps? Are you really able to debug PIE code on the target just by fooling the debugger about it like this? I would expect that it would fail to work if it really doesn't support PIE?
Best regards,
Wolfgang Denk

Hi Wolfgang,
On Fri, 2014-12-26 at 11:00 +0100, Wolfgang Denk wrote:
Dear Alexey,
In message 1419587516-30541-1-git-send-email-abrodkin@synopsys.com you wrote:
MetaWare debugger doesn't support PIE (position-independent executable) so the only way to load U-Boot in MDB is to fake it by:
- Reset PIE flag in ELF header
- Strip all debug information from elf
Even though it could be done manually but having this automated way is very convenient. User may build U-Boot that will be loaded on target via MDB saying "make mdbtrick".
I wonder if such manipulation helps? Are you really able to debug PIE code on the target just by fooling the debugger about it like this? I would expect that it would fail to work if it really doesn't support PIE?
Well the point is MDB is still used as a primary tool for interaction with target via JTAG. Moreover some very advanced features are not yet implemented in GDB for ARC (and not sure if they will be implemnted sometime soon given complexity and rare need for those features for common user).
So if we're talking about development process when U-Boot is loaded in target memory not by low-level boot-loader but manually through JTAG chances are high developer uses MDB for it.
Without manipulation we're talking about (BTW I got it documented quite a while ago here http://www.denx.de/wiki/U-Boot/ARCNotes) MDB will refuse to even start - so no chance to load elf contents on target.
Then if we now apply the manipulation MDB will happily start and will load all required sections into the target.
Indeed there will be no source-level debug info available. And still MDB will do its work on showing disassembly, registers, accessing low-level debug facilities etc.
So as a summary - this is pretty dirty hack but it simplifies life a lot for us.
Hope this explanation makes sense.
-Alexey

Dear Alexey,
In message 1419589068.3584.10.camel@synopsys.com you wrote:
Then if we now apply the manipulation MDB will happily start and will load all required sections into the target.
Indeed there will be no source-level debug info available. And still MDB will do its work on showing disassembly, registers, accessing low-level debug facilities etc.
So as a summary - this is pretty dirty hack but it simplifies life a lot for us.
Hope this explanation makes sense.
Yes, now I understand. maybe the commit message should be a bit more detailed for the benefit of those who are not familiar with this architecture.
Thanks.
Best regards,
Wolfgang Denk
participants (2)
-
Alexey Brodkin
-
Wolfgang Denk