Re: bugfix: _barebox_image_size wrong if enable

[Sascha Hauer <s.hauer@pengutronix.de>]

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox