[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: