On Mon, Jun 17, 2019 at 09:37:19PM +0800, 张忠山 wrote:
> When a pbl image uncompress and call the normal barebox, In
> barebox_non_pbl_start() it should call relocate_to_adr() to relocate barebox
> to barebox_base. Ofcouse CONFIG_RELOCATABLE enabled.
>
> And barebox_base calculated by:
>
> #define barebox_image_size (unsigned int)&_barebox_image_size
>
> unsigned long barebox_size = barebox_image_size +
> ((unsigned long)&__bss_stop - (unsigned long)&__bss_start);
>
> _barebox_image_size, __bss_stop, __bss_start all defined in linkscript
> "arch/arm/lib32/barebox.lds.S"
>
> But when I print there value in function barebox_non_pbl_start() with the
> flowwing code:
>
> putc_ll('X');
> putc_ll('\r');
> putc_ll('\n');
> PUTHEX_LL(barebox_size);
> putc_ll('\r');
> putc_ll('\n');
> PUTHEX_LL((unsigned long)&__bss_start);
> putc_ll('\r');
> putc_ll('\n');
> PUTHEX_LL((unsigned long)&__bss_stop);
> putc_ll('\r');
> putc_ll('\n');
>
> The result as floww:
>
> X
> 00000000
> 00000000
> 00000000
>
> It's so strange, SO objdump it:
>
> 00017424 <barebox_non_pbl_start>:
> 17424: e59f61a0 ldr r6, [pc, #416] ; 175cc <barebox_non_pbl_start+0x1a8>
> 17428: e080a001 add sl, r0, r1
> 1742c: e59f919c ldr r9, [pc, #412] ; 175d0 <barebox_non_pbl_start+0x1ac>
> 17430: e1a08000 mov r8, r0
> 17434: e92d4890 push {r4, r7, fp, lr}
> 17438: e0895006 add r5, r9, r6
> 1743c: e59fb190 ldr fp, [pc, #400] ; 175d4 <barebox_non_pbl_start+0x1b0>
> 17440: e3a00058 mov r0, #88 ; 0x58
> 17444: e1a07002 mov r7, r2
> 17448: ebfffca7 bl 166ec <PUTC_LL>
> 1744c: e06b5005 rsb r5, fp, r5
> 17450: e3a0000d mov r0, #13
> 17454: ebfffca4 bl 166ec <PUTC_LL>
> 17458: e3a0000a mov r0, #10
> 1745c: ebfffca2 bl 166ec <PUTC_LL>
> 17460: e1a00005 mov r0, r5
> 17464: ebffffe0 bl 173ec <PUTHEX_LL>
> 17468: e3a0000d mov r0, #13
> 1746c: ebfffc9e bl 166ec <PUTC_LL>
> 17470: e3a0000a mov r0, #10
> 17474: ebfffc9c bl 166ec <PUTC_LL>
> 17478: e1a0000b mov r0, fp
> 1747c: ebffffda bl 173ec <PUTHEX_LL>
> 17480: e3a0000d mov r0, #13
> 17484: ebfffc98 bl 166ec <PUTC_LL>
> 17488: e3a0000a mov r0, #10
> 1748c: ebfffc96 bl 166ec <PUTC_LL>
> 17490: e1a00006 mov r0, r6
> 17494: e24a6906 sub r6, sl, #98304 ; 0x18000
> 17498: ebffffd3 bl 173ec <PUTHEX_LL>
> 1749c: e3c66dff bic r6, r6, #16320 ; 0x3fc0
> 174a0: e3a0000d mov r0, #13
> ......
> 175c4: ebffa2c5 bl e0 <mem_malloc_init>
> 175c8: ebffa5a5 bl c64 <start_barebox>
> 175cc: 00000000 andeq r0, r0, r0
> 175d0: 00000000 andeq r0, r0, r0
> 175d4: 00000000 andeq r0, r0, r0
> 175d8: 00022448 andeq r2, r2, r8, asr #8
> 175dc: d00dfeed andle pc, sp, sp, ror #29
>
>
> We can see it save __bss_start and __bss_stop in local literal pool located at
> 175cc and 175d0, The value is zero. But in barebox.map it's
>
> 0x00000000000207b0 . = ALIGN (0x4)
> 0x00000000000207b0 __bss_start = .
> ......
> 0x0000000000022458 __bss_stop = .
> 0x0000000000022458 _end = .
> 0x00000000000207b0 _barebox_image_size = __bss_start
>
>
> Why?? It's so strange! Is it a bug of toolchain?
No, it is corrected during runtime in relocate_to_current_adr(). It
seems older compilers need a runtime relocation fixup for this.
AFAIR this only happened for linker variables that point to absolute
addresses. Differences between addresses also worked with the older
compilers, and I think this is what your patch does: With this the
linker is smart enough to recognize _barebox_image_size as a relative
size and not an absolute address. So I think your patch is correct.
Unfortunately I can't find any toolchain anymore to reproduce this
issue.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
