[Prev][Next][Index][Thread]
Oskit and C++ (perhaps a little offtopic)
A quick query; I'm trying to develop a kernel which will use C++ objects
internally for several things. I'd figured that this would need a little
adjustment to get it to compile smoothly with the oskit - adding extern "C"
to headers and so forth - which seems to be working so far as it goes.
The problem comes at the link stage. While I expected that I would have to
add my own new and delete operators - not having a C++ library, obviously -
it appears that there are a few other functions that g++ needs to be
satisfied once you start creating objects - the linker can't resolve
__eh_pc
__throw
terminate(void)
Before I beat my brains out chasing this down (__eh_pc?), would there be
anyone hereabouts who's tried this before and knows what they need to be?
(code enclosed below, if it helps)
Thanks in advance,
Alistair
I have a relatively simple modification of the "multiboot" example kernel
for now:
(startup.cpp)
#include <oskit/x86/pc/base_multiboot.h>
#include <oskit/x86/base_cpu.h>
#include <oskit/clientos.h>
#include <oskit/c/stdio.h>
#include <globals.h>
#include <mm.h>
int main(int argc, char **argv)
{
extern char **environ;
unsigned i;
oskit_clientos_init();
kernel_version = new Version (1) ;
printf("\nI was given this command line, environment, and bootopts:\n");
for (i = 0; i < argc; i++)
printf(" argv[%d]: `%s'\n", i, argv[i]);
for (i = 0; environ[i]; i++)
printf(" environ[%d]: `%s'\n", i, environ[i]);
for (i = 0; i < oskit_bootargc; i++)
printf(" oskit_bootargv[%d]: `%s'\n", i, oskit_bootargv[i]);
multiboot_info_dump(&boot_info);
printf("\nI'm running on a...\n");
cpu_info_dump(&base_cpuid);
return 0;
}
and have put the necessary new/delete operator code in a separate file:
void * operator new (size_t nb) // global operator new
{
void * p = malloc (nb) ;
return (p) ;
}
void operator delete (void * p) // global operator delete
{
if (p) free (p) ;
}
> -----Original Message-----
> From: owner-oskit-users@fast.cs.utah.edu
> [mailto:owner-oskit-users@fast.cs.utah.edu]On Behalf Of Jay Lepreau
> Sent: 13 October 1999 09:23 PM
> To: Geoff Humphreys
> Cc: oskit-users@cs.utah.edu
> Subject: Re: OSKit and processes
>
>
>
> > I want all processes
> > to be in the same flat address space but protected from
> each other, as
> > opposed to how Unix does things where everything is in its
> own address
> > space. I am still in the early planning stages though and
> would love to
> > hear other people's analysis of the pros and cons of this
> memory model.
>
> In OS design this is a reasonable but fairly radical approach, called
> a "single address space" design. There is a lot of literature on it.
> It was very hot about six-10 years ago but has fallen out of fashion.
> SAS tends to go along with single-level stores and persistent object
> systems, because it enables many of their benefits, but is not
> necessarily coupled to them.
>
> http://www.cs.dartmouth.edu/cs_archive/sasos/sasos.html contains
> pointers to some dead and living SAS projects, an extensive
> bibliography, including abstracts, and and mailing list archives. The
> list is basically dead now, since as I said interest has mostly moved
> on. But it will probably come back; these things go in cycles.
>
> In the next SOSP (http://www.diku.dk/sosp99/), a premier OS
> conference, there is paper on a related topic that would probably be
> useful to you. It's about combining the x86's support for segments
> and pages to extend the kernel with little bits of untrusted code
> (supposedly run in a restricted execution environment). "Integrating
> segmentation and paging protection for safe, efficient and kernel/user
> extensions." T. Chiueh, G. Venkitachalam, P. Pradhan (State
> University of New York at Stony Brook).
>
> The final SOSP papers were all submitted yesterday, so if you
> write to the author or check his Web site I am sure you
> can get a copy. It's full of low-level grungy details.
>
> 'Mungi' (UNSW, Australia) is one SAS project that I think is still
> active or semi-active. Another one is 'Nemesis' (Cambridge, UK).
> You can find pointers on the Dartmouth page above.
>
> The OSKit would provide the needed infrastructure for such
> a SASOS but be warned that this stuff is complicated and
> you'd best do some reading and studying of others' code first.
Follow-Ups:
References: