What does your OS look like? (Screen Shots..)

raistlinthewiz · Post by **raistlinthewiz** » Fri Jul 04, 2008 4:55 am

inx · Post by **inx** » Tue Jul 08, 2008 12:32 am

=p Been working on this intermittently for around 6 months. Not a looker, but as of last build:

I've been very strict to my microkernel design principles, and it's been very slow going. =p
I take heart in the fact that it's not nearly as slow going as the HURD has been. lol
Anyway, that's multitasking. I've been working on a big restructure in the MM over the past week.
Finally finished it, and the screenshot would've been the exact same (not accounting for timing)
before I did, which is an accomplishment.

The repeating numbers are usermode processes
in a constant loop of triggering a software interrupt and passing the displayed numbers in EAX.
*shrug* Figured I'd post something a little different..

Adek336 · Post by **Adek336** » Tue Jul 08, 2008 2:14 am

Wow, all these screenshots are inspiring

Here's an example of panaLiX 0.08. A sysfail (kernel panic) situation results in a stacktrace with C++ name demangling and arguments passed to the functions. The sysfail message is also sent to port 0xE9 (bochs echo)

lukem95 · Post by **lukem95** » Tue Jul 08, 2008 4:06 am

nice debugger

your OS name made me laugh though - something to do with my tremendous immaturity no doubt

panaLiX

jal · Post by **jal** » Tue Jul 08, 2008 5:21 am

adek336 wrote:Here's an example of panaLiX 0.08. A sysfail (kernel panic) situation results in a stacktrace with C++ name demangling and arguments passed to the functions.

What name demangling routines do you use? And where do you get the argument information from?

JAL

Adek336 · Post by **Adek336** » Tue Jul 08, 2008 6:14 am

thanks lukem

well actually I never really noticed I had anal in my name

thanks for letting me know, though

I've written the demangler in accordance to http://www.codesourcery.com/public/cxx- ... l#mangling, well I've just checked my code and it's not perfectly beautiful, but then again I wasn't much of a coder back then, code here http://panalix.sourceforge.net/doxygen/ ... ource.html.
I can get to the arguments because I demangle the names in an exception handler and therefore I know the EBP value at the moment of crash http://panalix.sourceforge.net/doxygen/ ... tml#l00049. The argument is fetched from memory at http://panalix.sourceforge.net/doxygen/ ... tml#l00404. Unfortunately, in gcc 4.3 it seems to not work (in 3.3 it did).

cyr1x · Post by **cyr1x** » Tue Aug 05, 2008 4:10 am

My turn

JamesM · Post by **JamesM** » Tue Aug 05, 2008 4:31 am

Adek336 wrote:thanks lukem well actually I never really noticed I had anal in my name thanks for letting me know, though

I've written the demangler in accordance to http://www.codesourcery.com/public/cxx- ... l#mangling, well I've just checked my code and it's not perfectly beautiful, but then again I wasn't much of a coder back then, code here http://panalix.sourceforge.net/doxygen/ ... ource.html.
I can get to the arguments because I demangle the names in an exception handler and therefore I know the EBP value at the moment of crash http://panalix.sourceforge.net/doxygen/ ... tml#l00049. The argument is fetched from memory at http://panalix.sourceforge.net/doxygen/ ... tml#l00404. Unfortunately, in gcc 4.3 it seems to not work (in 3.3 it did).

Awesome! I've done a similar thing for Pedigree, here: http://pedigree.googlecode.com/svn/trun ... emangle.cc - You managed to condense your code down a lot more than I did, it seems. Pedigree can get its function arguments in the same way as you - it's pretty damn useful, as I'm sure you've found.

I also wrote this, however: http://pedigree.googlecode.com/svn/trun ... tomaton.cc - this parses DWARF-2.0 and 3.0 call frame information (.debug_frame sections) so that I can backtrace on systems without frame pointers, and on x86 with --omit-frame-pointer. Pretty useful too. I also patched gcc to force it to output call-frame instructions in the preamble of every function, so I also know where in memory function parameters are stored (again, for architectures without a navigable stack frame structure).

What architectures do you support, out of interest? (I saw an ::Arch:: somewhere in that stacktrace...)

James

Adek336 · Post by **Adek336** » Tue Aug 05, 2008 2:58 pm

Awesome! I've done a similar thing for Pedigree, here: http://pedigree.googlecode.com/svn/trun ... emangle.cc - You managed to condense your code down a lot more than I did, it seems. Pedigree can get its function arguments in the same way as you - it's pretty damn useful, as I'm sure you've found.

My code is condensed, but I can't say it's a total success - I failed to structure and comment it well, it takes me a lot of analysis to just understand what it does. I don't support templates as I didn't care to check what these are when I was coding this part of software

Also, the arguments which my code finds seem to be wrong, I presume that sometimes gcc makes functions pass arguments through registers, I tryied to look at disassemblies to see if that is the case, but I didn't really understand them.
I took a look at your code - great job! It's much better structured and divided into functions and maintainable.

I also wrote this, however: http://pedigree.googlecode.com/svn/trun ... tomaton.cc - this parses DWARF-2.0 and 3.0 call frame information (.debug_frame sections) so that I can backtrace on systems without frame pointers, and on x86 with --omit-frame-pointer. Pretty useful too. I also patched gcc to force it to output call-frame instructions in the preamble of every function, so I also know where in memory function parameters are stored (again, for architectures without a navigable stack frame structure).

What architectures do you support, out of interest? (I saw an ::Arch:: somewhere in that stacktrace...)

No support for additional debug information other than function name and arguments on my part... I didn't even think about the possibility to have code which didn't use EBP for frame pointers at that time

Patching gcc sounds very respectable

That'd be a lot of work, I assume?
I only support x86; I have a dedicated namespace only because I wanted to have it a little seperated.

JJeronimo · Post by **JJeronimo** » Tue Aug 05, 2008 4:58 pm

This is the output I get when I comment out the code that goes to usermode.

The user-mode program only clears the screen, at least for now.

JJ

quok · Post by **quok** » Sat Aug 09, 2008 9:35 am

JamesM wrote: I also wrote this, however: http://pedigree.googlecode.com/svn/trun ... tomaton.cc - this parses DWARF-2.0 and 3.0 call frame information (.debug_frame sections) so that I can backtrace on systems without frame pointers, and on x86 with --omit-frame-pointer. Pretty useful too. I also patched gcc to force it to output call-frame instructions in the preamble of every function, so I also know where in memory function parameters are stored (again, for architectures without a navigable stack frame structure).

Hmm, I'm working on the same thing right now for my OS. I previously doing stack dumps by navigating the stack frame on x86 (looking up function addresses from the symbol table, and names from the string table), but as you rightfully pointed out, that relies on the frame pointer (as well as a symbol table) and isn't all that portable between arches. I'm curious why you had to patch GCC to output the CFI, though. I just pass -fasynchronous-unwind-tables to gcc when I compile. This doesn't work for ASM code, you simply have to add the appropriate CFI instructions yourself.

All this CFI gets stored in the .eh_frame section actually (which is dictacted by the ABIs of IA64 and X86_64 for example). When compiling with -gdwarf2 then I'll also get (mostly) the same stuff in .debug_frame. (I say mostly because there are some slight differences aside from just ABI and vendor specified stuff.) I find the .eh_frame approach much easier because it's an allocatable section, so grub (as well as any bootloader that properly parses ELF headers) loads it automatically. In my linker script I just use this standard technique:

Code: Select all

.eh_frame ALIGN(4) : AT(ADDR(.eh_frame) - PAGE_OFFSET)
{
    __start_eh_frame = .;
    *(.eh_frame)
    __end_eh_frame = .;
}

This way I have pointers to the beginning and end of the .eh_frame section. .eh_frame is 4 byte aligned by default, but I explicitly state it anyway.

I pass -gdwarf2 because I do a lot of my development on OS X, and there (as well as on BSD), gcc -g defaults to the stabs debugging format. Even with this switch though, GCC still outputs some stabs sections even on linux, so I just discard them later in my linker script.

Sorry, didn't mean to hijack this thread too much.

Rich

Laksen · Post by **Laksen** » Sat Aug 09, 2008 2:21 pm

It has gotten a little further than last time I posted. Multitasking is mostly stable. The kernel memory manager is slightly broken and results in that the kernel might hang at times on a real machine.
The scheduler only works on a single core as there's no load balancing yet, although I have made it boot all AP's in a system

The userspace interface is designed around pretty tight integration into the kernel and dynamic linking in runtime between applications

milyges · Post by **milyges** » Sun Aug 10, 2008 12:10 am

Some screenshots from IdyllaOS 0.1-dev:

jal · Post by **jal** » Mon Aug 11, 2008 7:16 am

milyges wrote:Some screenshots from IdyllaOS 0.1-dev:

Which could very well be Linux running in QEMU :). That's one of the reasons I'm not fond of these POSIX OSes...

JAL

Brynet-Inc · Post by **Brynet-Inc** » Mon Aug 11, 2008 10:12 am

jal wrote:
milyges wrote:Some screenshots from IdyllaOS 0.1-dev:
Which could very well be Linux running in QEMU . That's one of the reasons I'm not fond of these POSIX OSes...

JAL

Keep your opinions to yourself, he develops his OS publicly, both source and disk images are available.

There is nothing wrong with "POSIX OSes", in fact, you're simply demonstrating your own ignorance.

OSDev.org

What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)