From: Reinhard Meyer <u-boot@emk-elektronik.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] futile c relocation attempt
Date: Tue, 05 Oct 2010 19:41:35 +0200 [thread overview]
Message-ID: <4CAB634F.3010303@emk-elektronik.de> (raw)
In-Reply-To: <4CAB52B4.1080303@free.fr>
Dear Albert ARIBAUD,
>> include/configs/top9000_9xe.h | 1 +
That's my board. Not in mainstream yet. Just sets the define there.
>> +#ifdef CONFIG_USE_C_RELOCATION
>> + /* TODO: check for identical source and destination */
>> + /* TODO: check for overlapping */
>> + /* copy image, including initialized data */
>> + debug ("memcpy(%08lx,%08lx,%ld)\n",
>> + addr, _TEXT_BASE, _bss_start_ofs);
>> + memcpy ((void *)addr, (void *)_TEXT_BASE, _bss_start_ofs);
>> + /* now fix the code */
>> + debug ("_dynsym_start_ofs=%08lx _rel_dyn_start_ofs=%08lx _rel_dyn_end_ofs=%08lx\n",
>> + _dynsym_start_ofs, _rel_dyn_start_ofs, _rel_dyn_end_ofs);
>> + for (rel_dyn_ptr = (Elf32_Rel *)(_TEXT_BASE + _rel_dyn_start_ofs);
>> + rel_dyn_ptr< (Elf32_Rel *)(_TEXT_BASE + _rel_dyn_end_ofs);
>> + rel_dyn_ptr++) {
>> + ulong *patchaddr = (ulong *) (rel_dyn_ptr->r_offset + gd->reloc_off);
>> + debug ("patch %08lx : %08lx\n",
>> + (ulong)patchaddr, (ulong)rel_dyn_ptr->r_info);
>> + switch (ELF32_R_TYPE(rel_dyn_ptr->r_info)) {
>> + case 23: /* rel fixup */
>> + *patchaddr += gd->reloc_off;
>> + break;
>> + case 2: /* abs fixup */
>> + {
>> + Elf32_Sym *sym = (Elf32_Sym *)(_TEXT_BASE + _dynsym_start_ofs);
>> + sym += ELF32_R_SYM(rel_dyn_ptr->r_info);
>> + *patchaddr = gd->reloc_off + sym->st_value;
>> + }
>> + break;
>> + default: /* unhandled fixup */
>> + break;
>> + }
>> + }
>> + /* clear BSS */
>> +# ifndef CONFIG_PRELOADER
>> + debug ("clearing BSS %08lx..%08lx\n",
>> + addr + _bss_start_ofs, addr + _bss_end_ofs);
>> + for (p = (ulong *)(addr + _bss_start_ofs);
>> + p< (ulong *)(addr + _bss_end_ofs);
>> + *p++ = 0)
>> + ;
>> +# endif
>> +#endif
>
> All of _bss_start_ofs, _rel_dyn_start_ofs, _rel_dyn_end_ofs,
> _dynsym_start_ofs and _bss_end_ofs are going to be modified by the
> relocation fixup loop. The compiler *might* preload them into
> registers... or not; which could cause issues with ..._end_ofs ones,
> because it could cause the loops to overflow/underflow.
They are not going to be modified, they are in the unrelocated location!
>
>> + debug ("calling relocate_code\n");
>> relocate_code (addr_sp, id, addr);
>
> Have you not just relocated and fixed up in the C code? If so,
> relocate_code (which would then become a misnomer) should have its own
> relocate and fixup code removed (your patch does not), and only perform
> the C environment (stack, etc) switch.
Incorrect. I removed the relocation (#ifndef) in start.S leaving only
setting of the SP and calling of board_init_r active. True for the misnomer...
It was supposed to be a quick hack, beauty comes later ;)
> Side note: if board_init_f handles relocation and fixup and
> relocate_code just does stack switch between board_init_f and
> board_init_r, then I'd rather board_init_f *return* to start.S rather
> than *call* it if that's possible. That would make the control flow less
> circuitous: begin in start.S, set a minimal stack, call board_init_f,
> returns to start.S, switch to final stack, calls (branches to) board_init_r.
I agree here. I would have board_init_f return the desired SP value,
for example, or let it return the gd pointer - something along that line.
Or one completely skips returning back to asm and sets the sp with an
asm() statement in "C", obtains a function pointer to board_init_r, adjusts
that and calls that function.
Amicalement,
Reinhard
next prev parent reply other threads:[~2010-10-05 17:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-05 14:48 [U-Boot] [PATCH] futile c relocation attempt Reinhard Meyer
2010-10-05 13:30 ` Reinhard Meyer
2010-10-05 16:30 ` Albert ARIBAUD
2010-10-05 17:41 ` Reinhard Meyer [this message]
2010-10-05 19:29 ` Albert ARIBAUD
2010-10-06 9:43 ` Graeme Russ
2010-10-06 9:48 ` Reinhard Meyer
2010-10-06 10:20 ` Graeme Russ
2010-10-06 14:50 ` J. William Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CAB634F.3010303@emk-elektronik.de \
--to=u-boot@emk-elektronik.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox