Page 1 of 1
Export Symbol Table (or making libraries)
Posted: Mon Mar 30, 2009 1:52 pm
by instance
Hey,
I've been coding some functions for accessing keyboard... similar to getchar(). I've compiled the C file containing the function along with the rest of my kernel code.
Now I was wondering how can I write an application program that can access the getchar() function.
Is there any way I can find out which address the getchar function is loaded to.
I know I'm being quite unclear, but can any1 who had atleast a slight idea of what I said point me in the right direction on the wiki.... something perhaps related to making libraries for a new os or something..
Re: Export Symbol Table (or making libraries)
Posted: Mon Mar 30, 2009 1:58 pm
by Craze Frog
A userspace application or one running with the kernel?
Re: Export Symbol Table (or making libraries)
Posted: Mon Mar 30, 2009 2:34 pm
by instance
Actually, any application which is not linked directly into the kernel..
Re: Export Symbol Table (or making libraries)
Posted: Mon Mar 30, 2009 10:16 pm
by JamesM
instance wrote:Hey,
I've been coding some functions for accessing keyboard... similar to getchar(). I've compiled the C file containing the function along with the rest of my kernel code.
Now I was wondering how can I write an application program that can access the getchar() function.
Is there any way I can find out which address the getchar function is loaded to.
I know I'm being quite unclear, but can any1 who had atleast a slight idea of what I said point me in the right direction on the wiki.... something perhaps related to making libraries for a new os or something..
I
believe, although I may be mistaken, that you can link a program against any ELF file - even a fully-compiled executable. So, you could add a header file for "getchar", or a prototype so that your code compiles, and then add your kernel to the end of the link line. The linker should then attempt to resolve any unresolved references in the kernel - which is exactly what you want.
Please do let me know if it works
Cheers,
James
Re: Export Symbol Table (or making libraries)
Posted: Tue Mar 31, 2009 1:00 am
by skyking
Or perhaps it's parsing the ELF file and the symbol table that is what you want? That would get you the possibility to resolve the symbol in runtime (ie dynamic linking). Look for the ELF specification (or whatever binary format you're using).
Re: Export Symbol Table (or making libraries)
Posted: Tue Mar 31, 2009 8:26 am
by Martijn
Does your getchar() function depend on any kernel functions or services? If this is not the case than you can put the getchar() code in a seperate .c file and compile it with your kernel and non-kernel applications. Otherwise you would have to go with berkus's system call approach, or use kernel modules.
JamesM wrote:...
I believe, although I may be mistaken, that you can link a program against any ELF file - even a fully-compiled executable. So, you could add a header file for "getchar", or a prototype so that your code compiles, and then add your kernel to the end of the link line. The linker should then attempt to resolve any unresolved references in the kernel - which is exactly what you want.
This will link the entire kernel executable into the target file. Not really a lightweight solution, but it should work though.
Re: Export Symbol Table (or making libraries)
Posted: Tue Mar 31, 2009 10:54 am
by JamesM
Martijn wrote:
JamesM wrote:...
I believe, although I may be mistaken, that you can link a program against any ELF file - even a fully-compiled executable. So, you could add a header file for "getchar", or a prototype so that your code compiles, and then add your kernel to the end of the link line. The linker should then attempt to resolve any unresolved references in the kernel - which is exactly what you want.
This will link the entire kernel executable into the target file. Not really a lightweight solution, but it should work though.
Not quite - the linker never copies an object file verbatim into the final executable - it (usually) deletes unreferenced code.
Re: Export Symbol Table (or making libraries)
Posted: Wed Apr 01, 2009 12:18 pm
by djsilence
Hi, guys! I have a question too.
See: if I need to call getchar() from any app I need to link my source of app with library. But what about task rings? I mean that code of getch() is ring0 made, and app is ring3. Or I am wrong? (Then how can it be, that I call code from ring3 and this code is ring3 but do the same as kernel's code that is in ring0?
)
Sorry, for strange (and some stupid) question...
Re: Export Symbol Table (or making libraries)
Posted: Wed Apr 01, 2009 1:07 pm
by Craze Frog
JamesM wrote:Martijn wrote:
JamesM wrote:...
I believe, although I may be mistaken, that you can link a program against any ELF file - even a fully-compiled executable. So, you could add a header file for "getchar", or a prototype so that your code compiles, and then add your kernel to the end of the link line. The linker should then attempt to resolve any unresolved references in the kernel - which is exactly what you want.
This will link the entire kernel executable into the target file. Not really a lightweight solution, but it should work though.
Not quite - the linker never copies an object file verbatim into the final executable - it (usually) deletes unreferenced code.
At least that's what people like to believe.
Re: Export Symbol Table (or making libraries)
Posted: Wed Apr 01, 2009 2:10 pm
by skyking
JamesM wrote:
I believe, although I may be mistaken, that you can link a program against any ELF file - even a fully-compiled executable. So, you could add a header file for "getchar", or a prototype so that your code compiles, and then add your kernel to the end of the link line. The linker should then attempt to resolve any unresolved references in the kernel - which is exactly what you want.
Normally you can't do that because when linking for producing a executable you'd remove relocation information (other required information might be removed as well). If you don't it's still a question whether the linker/loader accepts a object/executable as executable/object.