[U-Boot] lib_arm global data pointer

Drasko DRASKOVIC drasko.draskovic at gmail.com
Tue Jul 14 15:22:05 CEST 2009


Dear  Wolfgang Denk.

>On Mon, Jul 13, 2009 at 9:34 PM, Wolfgang Denk <wd at denx.de> wrote:
> When I wrote "GCC's register usage conventions" I usually mean exactly
> that and not some completely different thing.
>
> You also might want to read the README. Search for "On ARM, the
> following registers are used"...
On a first glance README actually tells that U-Boot will respect ATCPS
(whith exception of r8, which it will reserve). So, actually, it can
be that we were talking about the same thing, just that I used term
ATPCS to underline that it is ARM (and not U-Boot or GCC) specific.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0042c/index.html
(http://www.nabble.com/Register-Usage-td23279910.html)

In any case, my code is working fine with r10 choice, which comes from
the reasons I elaborated before (although maybe r10 would not be the
happiest choice, but some of the regs r4-r9, r8 excluded).

> This has nothing to do with ISRs at all. What makes you think so?
This, for example:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=64978&postdays=0&postorder=asc
And this:
http://www.nabble.com/bug-or-feature--CSE-optimizes-away-global,-fixed-register-td23909408.html

This gave me a hint that people using "volatile register" vars mostly
in these cases.
And I was thinking myself: why claiming our local reg as volatile? Who
can change it appart from us, if not some other thread (written in
assembly most probably, because if it was a C call then GCC would
introduce prologue and epilogue to preserve register that are
guaranteed to be non clobbered by ATCPS). So what other thread do we
have in non-multithreaded U-Boot?
So, I grepped to see who the hell is touching r8, and all I could find
was (in cpu/armXXX/start.S) :
       .macro	irq_save_user_regs
	sub	sp, sp, #S_FRAME_SIZE
	stmia	sp, {r0 - r12}			@ Calling r0-r12
	@ !!!! R8 NEEDS to be saved !!!! a reserved stack spot would be good.
	add	r8, sp, #S_PC
	stmdb	r8, {sp, lr}^		@ Calling SP, LR
	str	lr, [r8, #0]		@ Save calling PC
	mrs	r6, spsr
	str	r6, [r8, #4]		@ Save CPSR
	str	r0, [r8, #8]		@ Save OLD_R0
	mov	r0, sp
	.endm
chunk of code in ISR.

So, my suspicions comes from there.

> The GCC mailing list is where GCC experts can answer your  questions.
> I'm not a GCC expert - just a happy user since version 1.35 or so...
Thanks, I will investigate this interesting topic further and post on
this thread if I come with reasonable solution. As I mentioned, my gcc
was not working as I expected with "register volatile", as it was
doing some optimization exibitions rather than plain register
read/mov.

Some questions are also worth mentioning:

        /* Pointer is writable since we allocated a register for it */
	gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));

Would not it be writable even if we did not allocated reg for it? We
could have declared it as a global var without asm("r8") stuff and
compiler would have put it on the stack - but I guess it would be
writable.

And then:
	/* compiler optimization barrier needed for GCC >= 3.4 */
	__asm__ __volatile__("": : :"memory");

Why is order of ams instructions important here?
(I did not had time yet to recompile without this membar before
posting this question, so I will try to do it and reproduce the
problem).


Best regards,
Drasko DRASKOVIC


More information about the U-Boot mailing list