printf, ..., va_start, va_end...

[LOneWoolF]

Hi guys
after a long pause i come back to develope my OS
now under linux... much more comfortable
now to my question....I have no idea ...:

how can i write a working printf wich handles the "..."-arguments?
the problem is, where can i find a whole definition of va_start and va_end?
and how do i have to write the vsprintf?

i had a look at the liinux kernel of osdev.neopages.net, but va_end -==> is defined in GNU lib
so i can't look at it...

any GOOD tutorials for that?
or a thread where you talked about it?

GreeZ
LOneWoolF

[Pype.Clicker]

actually, va_start, va_arg and va_end are declared in stdarg.h
This is indeed a part of the C standard library, but it's just a header file and va_xxx() are macros and not functions, so there shouldn't be any problem using them in your own work (i personnaly imported that file in Clicker with a few minor changes).

Code: Select all

/** this code is distributed under Gnu Public License */

/* sets the ArgumentPointer to the one past LASTARG */
#define va_start(AP, LASTARG)                                           \
 (AP = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))

/* returns the value of the current argument (assuming it's from TYPE)
   Side Effect: sets the ArgumentPointer to the next argument
*/
#define va_arg(AP, TYPE)                                                \
 (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)),     \
  *((TYPE *) (void *) ((char *) (AP) - __va_rounded_size (TYPE))))

#else
#error "Arguments System Not ported to this architecture, sorry."
#endif

check out /usr/include/stdarg.h ...

writing such macro from scratch is pretty awkward as there are a lot of dependencies to GCC internals (try out info gcc).

[LOneWoolF]

i added a stdarg.h
and a vsprintf function

the ... is not even used... but the pc restarts

without changing anything in the main function...

lol
my kernel size is
1056696 bytes

and a working one with MUCH MORE functions and loz of other stuff is
64219 bytes

why that???

i add some filez from the other kernel...
trying...
trying...
lol, same problem

ill add a zip with my kernel, using arg-stuff of queegs kernel (didn't really find problems that are caused by his code, just type definitions and so on, the vsprintf is used from linuxkernel<-), and my stdarg.h
plz sb have a look...

[attachment deleted by admin]

[Pype.Clicker]

imho, you must have something wrong in your linker script: you have actually a small block of 0xd0 bytes at the start of your file (which looks like a pointer table or something), then a huge hole of zeroes until address 0x000fffb0 is reached ... i dunno what you use to load your kernel nor where it is supposed to be placed, etc. but it really seems to me that you messed things up ...

I would suggest you to give a closer look at your building process ...

[LOneWoolF]

Funny, i just rewrote my Makefile(now -s = MakefileS) while you wrote that...
now the vsprintf is in a libc.so
kernel size: 8192 bytes
libc.so size: 3574 bytes (will grow a few bytes...)
that sizes seem to be correct, don't they?

now i need to get a bit of advanced assambler-language-usage-information
i never loaded filez using asm...
any interesting tutorials on how i can load the libc.SO into memory? i mean, i'm a c programmer
do i need memory management to handle that library correctly?

PLEASE gimme some infopages

before givin' me some sources... list a few pages where i can get information about that libraries PLEASE!
and PLEASE also some pages with examples on loading them

AND NOW i gonna read that bootloader ASM, it LOADS the file of the FAT system.... that could be interesting

[Pype.Clicker]

if you really want to load libc.so (this is, a dynamic ELF library) with your kernel, you should read "linkers and loaders" book (should be in the "book recommandation" thread).
However, you should know that loading a dynamic ELF object is *not* a trivial task at all and can hardly be done in assembly in a bootloader.

if i could afford a suggestion, i would tell that you should better link your libc and your kernel together at build time (using ld) to produce one big file that can be loaded at once. imho, it will be easier to handle...

[LOneWoolF]

ok, and what if i don't create a shared library, but just a binary file?

then i can load that, like the bootloader loads kernel.bin, right?

the problem is vsprintf.o

when i link that to my kernel, my kernel growes some megabytes...

added a zip file

the vsprintf function isn't complete here and my Makefiles are a bit weird

can you give me a working kernel wicht just does
k_clear_screen();
printf("Hi %i", num);

nothing else,
just the vsprintf-system
and a clear_screen

so that i can compare it?

BUT the vsprintf shall be in an extra file...
BECAUSE

OH; ***;

WHEN I COPY THE WHOLE TEXT (but the includes) INTO MY MAIN KERNEL FILE
IT WORKS PERFECT

***

I THINK it is the "goto-loop", while rewriteing vsprintf.c, i often tried it out before going on wirting, after adding the "goto-loop" the kernel GREW!!!

[attachment deleted by admin]

[Pype.Clicker]

okay. found it... you were missing the ".rodata" in your linker script. This is the section where displayable strings are stored in ELF files. As you omitted it in link.ld, the linker assumed it should go to offset 0 while your whole kernel was linked at 0x100000, which explains the size problem (and probably the fact the kernel wasn't running anymore -- as the loader probably started a string rather than some code :p )

just add "*(.rodata*)" after "*(.text)" and it should compile correctly ...

[LOneWoolF]

THANX i gonna try that now

YESSSSS
THAT WORKS NOW THANX!!!

displayable strings---
but shouldn't the -fwritable-strings obtion for gcc be sth to avoid that problem too?