On 17:16 Tue 31 Jul , Erwin Rol wrote: > Hey Sascha, > > On 31-7-2012 15:13, Sascha Hauer wrote: > >Hi Erwin, > > > >On Tue, Jul 31, 2012 at 12:49:29PM +0200, Erwin Rol wrote: > >>Hey x86-asm-experts, > > > >Surely you do not mean me ;) > > > >> > >>On 31-7-2012 0:36, Erwin Rol wrote: > >> > >>So when I use the memset code the asm looks like this below. As you > >>can see the memset gets its 3 parameters from the stack (see > >>comments below in the asm src). But when you look at the location > >>when memset is called it looks like the caller tries to pass the > >>parameters in registers. After looking into the Makefile I noticed > >>the arch/x86/boot/* sources get compiled with -mregparm=3, but the > >>other sources use normal calling convention. This means code from > >>arch/x86/boot/* can not call any other barebox functions when they > >>are not of type void f(void). The file arch/x86/boot/regs.c also > >>calls memset but it seems the compiler notices that regs.c is 16bit > >>code and so it inlines a 16bit memset version (I at least don't see > >>a call function). > >> > >>Is there any GCC or LD magic we can use to prevent error like this? > >>Wouldn't it be better to _not_ change the calling convention in the > >>Makefile, but mark the functions that need it with __attribute__ ? > > > >Maybe it's easier and more straight forward to just use a for-loop here > >instead of playing magic games with attributes and or flags? Are there > >more functions affected or is it just memset? > > There seem to be two memset calls, that could be problematic. Both > should be easily replaceable with for-loops (like I already did by > the first). > > We just have to be very careful to not call any functions from > outside the boot dir (expect for the main barebox entry point). > > Don't you love the weird x86 world :-) so I guess we should update the x86 to use the pbl so we can have two explicit part of binary and we can avoid those issue Best Regards, J. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox