* x86 weirdness @ 2012-07-30 22:36 Erwin Rol 2012-07-31 10:49 ` Erwin Rol 0 siblings, 1 reply; 7+ messages in thread From: Erwin Rol @ 2012-07-30 22:36 UTC (permalink / raw) To: barebox Hallo, after I had successfully "ported" barebox to about 5 different embedded x86 (mostly N270 and Z510 Atom boards) I ran into problems with a Celeron SU2300 CPU based board. After a lot of trail and error, which included the implementation of a BIOS based console cause the board does not have a RS232 port, it looked like the global variables were not what I expected them to be, namely zero. So in arch/x86/boot/main_entry.c i changed to following; /** * Called plainly from assembler that switches from real to flat mode * * @note The C environment isn't initialized yet */ void uboot_entry(void) { #if 0 /* clear the BSS first */ memset(__bss_start, 0x00, __bss_stop - __bss_start); #else unsigned char* ptr; for (ptr = __bss_start; ptr < __bss_stop; ptr++) *ptr = 0x00; #endif start_barebox(); } After doing that it works. I have not yet looked into the resulting asm to find the differences, but could someone have an explanation for why the memset doesn't work and the simple loop does work? - Erwin _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: x86 weirdness 2012-07-30 22:36 x86 weirdness Erwin Rol @ 2012-07-31 10:49 ` Erwin Rol 2012-07-31 13:13 ` Sascha Hauer 0 siblings, 1 reply; 7+ messages in thread From: Erwin Rol @ 2012-07-31 10:49 UTC (permalink / raw) To: barebox Hey x86-asm-experts, On 31-7-2012 0:36, Erwin Rol wrote: > Hallo, > > after I had successfully "ported" barebox to about 5 different embedded > x86 (mostly N270 and Z510 Atom boards) I ran into problems with a > Celeron SU2300 CPU based board. After a lot of trail and error, which > included the implementation of a BIOS based console cause the board does > not have a RS232 port, it looked like the global variables were not what > I expected them to be, namely zero. > > So in arch/x86/boot/main_entry.c i changed to following; > > /** > * Called plainly from assembler that switches from real to flat mode > * > * @note The C environment isn't initialized yet > */ > void uboot_entry(void) > { > #if 0 > /* clear the BSS first */ > memset(__bss_start, 0x00, __bss_stop - __bss_start); > #else > unsigned char* ptr; > for (ptr = __bss_start; ptr < __bss_stop; ptr++) > *ptr = 0x00; > #endif > > > start_barebox(); > } > > > After doing that it works. I have not yet looked into the resulting asm > to find the differences, but could someone have an explanation for why > the memset doesn't work and the simple loop does work? 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__ ? 00023e98 <in_pm32>: 23e98: 8e d9 mov %ecx,%ds 23e9a: 8e c1 mov %ecx,%es 23e9c: 8e e1 mov %ecx,%fs 23e9e: 8e e9 mov %ecx,%gs 23ea0: 8e d1 mov %ecx,%ss 23ea2: bc c8 f8 03 00 mov $0x3f8c8,%esp 23ea7: 0f 00 df ltr %di 23eaa: 31 c9 xor %ecx,%ecx 23eac: 31 d2 xor %edx,%edx 23eae: 31 db xor %ebx,%ebx 23eb0: 31 ed xor %ebp,%ebp 23eb2: 31 ff xor %edi,%edi 23eb4: 0f 00 d1 lldt %cx 23eb7: e9 00 00 00 00 jmp 23ebc <uboot_entry> 00023ebc <uboot_entry>: // calculate (3rd parameter) size and put it in %ecx 23ebc: b9 c8 78 03 00 mov $0x378c8,%ecx 23ec1: 81 e9 70 a2 02 00 sub $0x2a270,%ecx // clear %edx (2nd paremeter) 23ec7: 31 d2 xor %edx,%edx // start address in %eax (1st parameter) 23ec9: b8 70 a2 02 00 mov $0x2a270,%eax 23ece: e8 e6 0b ff ff call 14ab9 <memset> 23ed3: e9 4c a4 fe ff jmp e324 <start_barebox> 00014ab9 <memset>: 14ab9: 55 push %ebp 14aba: 89 e5 mov %esp,%ebp 14abc: 53 push %ebx // get parameter 1 (dst address) 14abd: 8b 45 08 mov 0x8(%ebp),%eax // get parameter 2 (src byte to fill) 14ac0: 8b 5d 0c mov 0xc(%ebp),%ebx // get parameter 3 (size) 14ac3: 8b 4d 10 mov 0x10(%ebp),%ecx 14ac6: 31 d2 xor %edx,%edx 14ac8: eb 04 jmp 14ace <memset+0x15> 14aca: 88 1c 10 mov %bl,(%eax,%edx,1) 14acd: 42 inc %edx 14ace: 39 ca cmp %ecx,%edx 14ad0: 75 f8 jne 14aca <memset+0x11> 14ad2: 5b pop %ebx 14ad3: 5d pop %ebp 14ad4: c3 ret _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: x86 weirdness 2012-07-31 10:49 ` Erwin Rol @ 2012-07-31 13:13 ` Sascha Hauer 2012-07-31 15:16 ` Erwin Rol 0 siblings, 1 reply; 7+ messages in thread From: Sascha Hauer @ 2012-07-31 13:13 UTC (permalink / raw) To: Erwin Rol; +Cc: barebox 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? 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: x86 weirdness 2012-07-31 13:13 ` Sascha Hauer @ 2012-07-31 15:16 ` Erwin Rol 2012-07-31 15:51 ` Jean-Christophe PLAGNIOL-VILLARD 2012-07-31 17:07 ` Sascha Hauer 0 siblings, 2 replies; 7+ messages in thread From: Erwin Rol @ 2012-07-31 15:16 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 :-) - Erwin PS: I will prepare some x86 updates like bios-vga-output and GTP partition support that might be useful for others too. _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: x86 weirdness 2012-07-31 15:16 ` Erwin Rol @ 2012-07-31 15:51 ` Jean-Christophe PLAGNIOL-VILLARD 2012-07-31 16:16 ` Erwin Rol 2012-07-31 17:07 ` Sascha Hauer 1 sibling, 1 reply; 7+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-07-31 15:51 UTC (permalink / raw) To: Erwin Rol; +Cc: barebox 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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: x86 weirdness 2012-07-31 15:51 ` Jean-Christophe PLAGNIOL-VILLARD @ 2012-07-31 16:16 ` Erwin Rol 0 siblings, 0 replies; 7+ messages in thread From: Erwin Rol @ 2012-07-31 16:16 UTC (permalink / raw) To: Jean-Christophe PLAGNIOL-VILLARD; +Cc: barebox On 31-7-2012 17:51, Jean-Christophe PLAGNIOL-VILLARD wrote: > 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 One thing to know about the x86 support is that it uses (16bit) bios calls to load data from disk and print info on the (vga) screen. These calls are wrapped with special code to change from 32bit to 16bit and back. So I have no idea of "pbl" works with this very special x86 code. - Erwin > Best Regards, > J. > _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: x86 weirdness 2012-07-31 15:16 ` Erwin Rol 2012-07-31 15:51 ` Jean-Christophe PLAGNIOL-VILLARD @ 2012-07-31 17:07 ` Sascha Hauer 1 sibling, 0 replies; 7+ messages in thread From: Sascha Hauer @ 2012-07-31 17:07 UTC (permalink / raw) To: Erwin Rol; +Cc: barebox On Tue, Jul 31, 2012 at 05:16:26PM +0200, Erwin Rol wrote: > Hey Sascha, > > > 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). This is probably a good idea anyway since the bss is not cleared at this stage. > > Don't you love the weird x86 world :-) I'm glad that most of the time I don't have to care about x86 ;) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-07-31 17:08 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-30 22:36 x86 weirdness Erwin Rol 2012-07-31 10:49 ` Erwin Rol 2012-07-31 13:13 ` Sascha Hauer 2012-07-31 15:16 ` Erwin Rol 2012-07-31 15:51 ` Jean-Christophe PLAGNIOL-VILLARD 2012-07-31 16:16 ` Erwin Rol 2012-07-31 17:07 ` Sascha Hauer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox