Menu
▾
▴
oslib-devel
|
From: Giacomo G. <gu...@li...> - 2003-03-19 14:09:27
|
Hi all
I found that the cmdline inside the multiboot structure
is modified by the argc,argv elaboration
/oslib/xlib/x1.c
function _startup(void)
it cause a fail getting argc argv when the cmdline is reused outside
the oslib (ex: s.ha.r.k.)
so I suggest this correction (diff) where I defined and use a temp var.
Index: x1.c
===================================================================
RCS file: /home/cvs/cvsroot/shark/oslib/xlib/x1.c,v
retrieving revision 1.2
diff -u -r1.2 x1.c
--- x1.c 30 Jan 2003 09:24:16 -0000 1.2
+++ x1.c 19 Mar 2003 13:05:25 -0000
@@ -98,6 +98,7 @@
void _startup(void)
{
register int i = 0;
+ char temp[1000];
struct multiboot_info *mbi = mbi_address();
char *cmdline = (char *)(mbi->cmdline);
@@ -105,16 +106,21 @@
cputs("X/Runtime library error!!! Unable to find memory
information!\n");
l1_exit(-1);
}
-
+
if (mbi->flags & MB_INFO_CMDLINE) {
/* Build parameter list, up to 100 parms... */
- while (cmdline[i] != 0) {
- _argv[_argc] = &(cmdline[i]);
- while (cmdline[i] != ' ' && cmdline[i] != 0) i++;
+ while (cmdline[i] != 0 && i < 1000) {
+ temp[i] = cmdline[i];
+ _argv[_argc] = &(temp[i]);
+ while (cmdline[i] != ' ' && cmdline[i] != 0 && i < 1000) {
+ temp[i] = cmdline[i];
+ i++;
+ }
if (cmdline[i] == ' ') {
- cmdline[i] = 0; i++; _argc++;
+ temp[i] = 0; i++; _argc++;
}
}
+ temp[i] = 0;
_argc++;
}
@@ -122,15 +128,16 @@
/* Call main procedure using standard C convention */
/* Remember you cannot call any console I/O function */
/* if you do not call bios_save() */
-
+
+
#ifdef __DUMP_MEM__
message("X/MEM : %u\n",mbi->mem_upper);
message("DOS/MEM : %u\n",mbi->mem_lower);
message("x_bios Size : %u\n",sizeof(X_BIOSCALL));
message("mbi Size : %u\n",sizeof(struct multiboot_info));
message("Cmdline : %s\n",mbi->cmdline);
- message("Argc : %u",_argc);
- message("Argv[0] : %s / %s\n",_argv[0]);
+ message("Argc : %u\n",_argc);
+ message("Argv[0] : %s\n",_argv[0]);
message("Argv[1] : %s\n",_argv[1]);
message("Argv[2] : %s\n",_argv[2]);
message("Argv[3] : %s\n",_argv[3]);
|
|
From: Paolo G. <pao...@ev...> - 2003-03-19 15:02:35
|
Hi Luca, Hi Giacomo...
what I really think about this issue is that the whole _startup function
should be customizable by the user.
That is, if we are using oslib only all remains like that, if we are
using our kernel based on OsLib, we should be able to write our own
_startup functions.
In fact, if you remove the command line mangling part, it remains only a
bios_save() and a bios_restore().
If this way is taken, there is no more need to have the "MAIN" define to
use a predefined OsLib's main() function or the kernel's "init"
function...
what do you think about that??? the code would be something like the one
in the bottom of the mail... and it seems in my opinion more simple...
bye
PJ
xlib/x1.c
-------------
[....]
DWORD _stkbase;
DWORD _stktop;
/* This is some extra stuff we need to compile with argument */
/* passing and math extensions */
DWORD _argc = 0;
typedef char *charp;
charp _argv[100];
#ifndef NO_MAIN
extern void main(int argc,char *argv[]);
extern void bios_save(void);
extern void bios_restore(void);
/* This is used in GNU-C to implement C++ constructors/destructors */
/* See the lib sources for more details */
void __main(int argc, char **argv)
{
}
struct multiboot_info * mbi_address(void)
{
/* This is declared in [wc32/gnu]\x0.[asm/s] */
extern struct multiboot_info *mbi;
return (mbi);
}
void _startup(void)
{
[...] as now, but main and not MAIN at the end
}
#endif
On Wed, 2003-03-19 at 15:09, Giacomo Guidi wrote:
> I found that the cmdline inside the multiboot structure
> is modified by the argc,argv elaboration
> /oslib/xlib/x1.c
>
> function _startup(void)
>
> it cause a fail getting argc argv when the cmdline is reused outside
> the oslib (ex: s.ha.r.k.)
>
> so I suggest this correction (diff) where I defined and use a temp var.
--
-----------------------------------------------------------------------
Paolo Gai - ReTiS Lab - PhD Student
Scuola Superiore S. Anna Tel : +39 050 883 451
Polo S. Anna Valdera Fax : +39 050 883 452
viale Rinaldo Piaggio 34 e-mail : pj...@ga...
56025 - Pontedera (PI) - ITALY home page : http://feanor.sssup.it/~pj
------------------------------------------------------------------------
Per favore non mandatemi allegati in Word o PowerPoint.
(Please avoid sending me Word or PowerPoint attachments.)
Si veda (See) http://www.fsf.org/philosophy/no-word-attachments.html
------------------------------------------------------------------------
|
|
From: Luca A. <luc...@em...> - 2003-03-19 15:33:07
|
Hi,
On Wed, 2003-03-19 at 15:02, Paolo Gai wrote:
> Hi Luca, Hi Giacomo...
>
> what I really think about this issue is that the whole _startup function
> should be customizable by the user.
>
> That is, if we are using oslib only all remains like that, if we are
> using our kernel based on OsLib, we should be able to write our own
> _startup functions.
>
> In fact, if you remove the command line mangling part, it remains only a
> bios_save() and a bios_restore().
>
> If this way is taken, there is no more need to have the "MAIN" define to
> use a predefined OsLib's main() function or the kernel's "init"
> function...
>
> what do you think about that??? the code would be something like the one
> in the bottom of the mail... and it seems in my opinion more simple...
I think the solution is to have a STARTUP macro in xo.s, instead of a
MAIN macro in x1.c... If you think it is ok, I'll commit a change on the
cvs.
Regarding the original (argv) problem, I'd prefer to commit something
like this, if it works ok for you:
Index: xlib/x1.c
===================================================================
RCS file: /cvsroot/oslib/oslib/xlib/x1.c,v
retrieving revision 1.4
diff -r1.4 x1.c
77a78,79
> #define MAX_ARG_SIZE 1024
> static char private_args[MAX_ARG_SIZE];
102d103
< char *cmdline = (char *)(mbi->cmdline);
111,115c112,118
< while (cmdline[i] != 0) {
< _argv[_argc] = &(cmdline[i]);
< while (cmdline[i] != ' ' && cmdline[i] != 0) i++;
< if (cmdline[i] == ' ') {
< cmdline[i] = 0; i++; _argc++;
---
> memcpy(private_args, (char *)mbi->cmdline, MAX_ARG_SIZE);
> private_args[MAX_ARG_SIZE - 1] = 0;
> while (private_args[i] != 0) {
> _argv[_argc] = &(private_args[i]);
> while (private_args[i] != ' ' && private_args[i] != 0) i++;
> if (private_args[i] == ' ') {
> private_args[i] = 0; i++; _argc++;
Luca
|
|
From: Luca A. <luc...@em...> - 2003-03-20 08:38:14
|
Hi Paolo, On Thu, 2003-03-20 at 08:15, Paolo Gai wrote: > > I think the solution is to have a STARTUP macro in xo.s, instead of a > > MAIN macro in x1.c... If you think it is ok, I'll commit a change on the > > cvs. > > Yes!!!... in that way, we should be able to customize all the startup > phase... Ok, I'll do it, and commit it during my lunch break > > ...and what happens to the _startup function in xlib/x1.c? ... maybe if > a user wants a customized startup phase he do not need anymore that > function... I think the options in this case are two: > - not to compile xlib/x1.c > - compile it with the _startup function "removed" through #ifdef... I would go for the third solution: move _startup() (and all the variable referenced by it) in a new object file. The linker is smart enough to avoid linking that file if there is no reference to _startup(). Luca |
|
From: Kniffo v. S. <kn...@ya...> - 2003-03-19 18:48:28
|
Hello everyone, this is my first posting here :) I tried to build the examples on win32: The libs have been well. Everything can be found in "lib", but with the examples I have some problems... I am compiling and linking with the win32-gcc MingW32. If I try to compile and link them, just typing "make" in examples, it spits out these error messages: -snip- gcc -Wall -O -finline-functions -fno-builtin -nostdinc -D__GNU__ -I.. -c mbdemo.c ld -T ../mk/os.x -Bstatic -Ttext 0x320000 -oformat coff-go32 -s -nostartfiles -n ostdlib -L../lib/ ../lib/x0.o mbdemo.o --start-group -lhc -lhm -lhx -lkl -lcons --end-group -o mbdemo.xtn ld: target coff-go32 not found make: *** [mbdemo.xtn] Error 1 rm mbdemo.o -snip- Well, do you see the problem? I looked into the helpfiles to ld and looked up the usage of the win32 ld and there are no problems in creating and using custom build-scripts... so I dont know the problem.. Can you help me out ppl?? Thanx, Carsten __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Luca A. <luc...@em...> - 2003-03-20 09:00:01
|
Hi Carsten, > I tried to build the examples on win32: > > The libs have been well. Everything can be found in > "lib", but with the examples I have some problems... > > I am compiling and linking with the win32-gcc MingW32. The problem is that mingw32 is currently not supported. We support the linux gcc (producing ELF files) and DJGPP (producing multiboot coff files). You probably copied dos.mk in config.mk, so the build system is configured to use DJGPP, and is trying to generate a coff file, that is not supported by the mingw32 linker. Simple solution: install DJGPP (it works under windows, too) from http://www.delorie.com. More complex solution: generate a config.mk file that can be used with mingw32. Obviously, you have to change the -oformat coff-go32 option, and probably you have to change the os.x linker script. I remember that I was able to compile the examples with cygwin ont time, and that there was some weird problem related to the main and start symbols (the windows compiler uses different names, if I remember well). I'll try to have a look at the problem, and to generate a win.mk file in the next days. Luca |
|
From: Paolo G. <pao...@ev...> - 2003-03-20 08:15:28
|
> I think the solution is to have a STARTUP macro in xo.s, instead of a > MAIN macro in x1.c... If you think it is ok, I'll commit a change on the > cvs. Yes!!!... in that way, we should be able to customize all the startup phase... ...and what happens to the _startup function in xlib/x1.c? ... maybe if a user wants a customized startup phase he do not need anymore that function... I think the options in this case are two: - not to compile xlib/x1.c - compile it with the _startup function "removed" through #ifdef... > Regarding the original (argv) problem, I'd prefer to commit something > like this, if it works ok for you: [...] I think it works and it is fine. In our case (shark), anyway, this code will not be used since we'll maybe simply customize the _startup... bye PJ |
|
From: Paolo G. <pao...@ev...> - 2003-03-20 08:42:52
|
> > Yes!!!... in that way, we should be able to customize all the startup > > phase... > Ok, I'll do it, and commit it during my lunch break Thank you, Luca!!! :-))))) > I would go for the third solution: move _startup() (and all the variable > referenced by it) in a new object file. The linker is smart enough to > avoid linking that file if there is no reference to _startup(). Perfect!!! Btw, we found another bug on the irq handling related to the slave interrupt controller... Giacomo or Michael will send the patch on the mailing list during this morning!!! bye PJ |
|
From: Luca A. <luc...@em...> - 2003-03-20 12:44:00
|
Ok, I just committed some changes to the cvs... Have a look, and let me know if they are ok. Since I have not too much time, I only did a limited testing, but the examples seem to still build and work correctly (at least in bochs). > Btw, we found another bug on the irq handling related to the slave > interrupt controller... Giacomo or Michael will send the patch on the > mailing list during this morning!!! Ok, I'll commit the patch as soon as I receive it. Luca |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X