Page 15 of 262
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Jul 04, 2008 4:55 am
by raistlinthewiz
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jul 08, 2008 12:32 am
by inx
=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..
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jul 08, 2008 2:14 am
by Adek336
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)
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jul 08, 2008 4:06 am
by lukem95
nice debugger
your OS name made me laugh though - something to do with my tremendous immaturity no doubt
p
anaLiX
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jul 08, 2008 5:21 am
by jal
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
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jul 08, 2008 6:14 am
by Adek336
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).
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Aug 05, 2008 4:10 am
by cyr1x
My turn
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Aug 05, 2008 4:31 am
by JamesM
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
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Aug 05, 2008 2:58 pm
by Adek336
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.
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Aug 05, 2008 4:58 pm
by JJeronimo
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
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Aug 09, 2008 9:35 am
by quok
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
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Aug 09, 2008 2:21 pm
by Laksen
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
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Aug 10, 2008 12:10 am
by milyges
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Aug 11, 2008 7:16 am
by jal
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
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Aug 11, 2008 10:12 am
by Brynet-Inc
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.
