u-boot/arch/arc/Makefile

#
# SPDX-License-Identifier:	GPL-2.0+
#

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
Kbuild: introduce Makefile in arch/$ARCH/ Introduce a Makefile under arch/$ARCH/ and include it in the top Makefile (similar to Linux kernel). This allows further refactoringi like moving architecture-specific code out of global makefiles, deprecating config variables (CPU, CPUDIR, SOC) or deprecating arch/$ARCH/config.mk. In contrary to Linux kernel, U-Boot defines the ARCH variable by Kconfig, thus the arch Makefile can only included conditionally after the top config.mk. Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com> 10 years ago			`#`
			`# SPDX-License-Identifier: GPL-2.0+`
			`#`

			`libs-y += arch/arc/cpu/$(CPU)/`
			`libs-y += arch/arc/lib/`
arc: introduce "mdbtrick" target MetaWare debugger (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. But MDB doesn't support PIE (position-independent executable) - it will refuse to even start - that means no chance to load elf contents on target. Then the only way to load U-Boot in MDB is to fake it by: 1. Reset PIE flag in ELF header This is simpe - on attempt to open elf MDB checks header and if it doesn't match its expectation refuces to use provided elf. 2. Strip all debug information from elf If (1) is done then MDB will open elf but on parsing of elf's debug info it will refuse to process due to debug info it cannot understand (symbols with PIE relocation). Even though it could be done manually (I got it documented quite a while ago here http://www.denx.de/wiki/U-Boot/ARCNotes) having this automated way is very convenient. User may build U-Boot that will be loaded on target via MDB saying "make mdbtrick". 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. But still MDB will do its work on showing disassembly, global symbols, registers, accessing low-level debug facilities etc. As a summary - this is a pretty dirty hack but it simplifies life a lot for us ARc developers. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Tom Rini <trini@ti.com> Cc: Wolfgang Denk <wd@denx.de> 10 years ago
			`# 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`