From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andreas_Bie=DFmann?= Date: Tue, 11 Jan 2011 14:07:13 +0100 Subject: [U-Boot] [PATCH RFC] armv7: fixloop: don't fixup if location is NULL In-Reply-To: <4D2C5482.9070800@gmail.com> References: <4D186A13.4080004@samsung.com> <24AA7201-FEC9-4485-837F-52CF0CBD06C4@googlemail.com> <4D284156.90305@free.fr> <20110110102052.7E30D150A44@gemini.denx.de> <20110110121453.67D51150A44@gemini.denx.de> <4D2B4002.2090408@free.fr> <4D2C5482.9070800@gmail.com> Message-ID: <4D2C5601.7030901@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Minkyu Kang, Am 11.01.2011 14:00, schrieb Andreas Bie?mann: > Dear Minkyu Kang, > > Am 11.01.2011 11:57, schrieb Minkyu Kang: > >>> Regardless of the patch, if your code writes to panel_info or any other BSS >>> variable before relocation it will trash the relocation tables that exist at >>> BSS location at this point. >>> >>> IOW, accessing BSS before relocation is forbidden, not just out of fancy, >>> but for a serious reason. >> >> This patch is not for accessing BSS before relocation, >> it's for prevent exceptions. > > The real error is writing to BSS before relocation. This leads to a > corrupted .rel.dyn section which is placed at the same address as .bss > at this moment (bss is overloaded to save space). > > If you look in your ELF (e.g. readelf -R .rel.dyn u-boot) you may see, > that the .rel.dyn section does _not_ include a pointer to 0x0 with > relative relocation (0x17) as you showed in a previous post. > If you look in your u-boot.map you may find the function in question > (test_func() was it in your example) is placed in .bss section. Setting > the function pointer to 0 (e.g. test_func() = NULL, as described in > previous mail) before relocation will destroy your .rel.dyn section and > then you will see a zero in .rel.dyn section at some place ... please > investigate the ELF and do not step through the code to find those issues. You may have a look at http://patchwork.ozlabs.org/patch/73760 for an TEST approach to see the damaged .rel.dyn, if you like this hackish approach. regards Andreas Bie?mann