OSDev.org

So, I've been at this for a while now - I've got a invalid opcode error somewhere and now I need a stacktrace to make sure, where it is. But.. my stacktrace code
refuses to work with me. I've tried every reasonable and unreasonable thing to fix this, to no luck. I'm starting to have thoughts of rewriting the OS completely. Perhaps any1 of you can be of help? https://github.com/makerimages/OSZin/issues/6

Where is the code. I can't find the code for the stacktrace on the page

Src/modules/elf.cpp

The easiest method of debugging is printing a message and halting. If the code doesn't fail (system reboots), then move that two lines of code (print and halt) down. If it fails, then go into the function that is called before printing a message (it may be an expression, but doesn't matter), research it, if you think that it's correct, then go to function's code (if it's a func) and do the same. However, there would be a man that will say that that method is bad for some reasons (e.g. it's a very "nooby" method, I agree with that ). I personally use it because of its simplicity, and it helped me a lot of times.

Yeah, but I'd still like a functioning stacktrace.

Reading EBP this way via using inline assembly in a function is rather dangerous and can give you wrong results, because GCC may do things with it you don't expect (since GCC doesn't expect you to read it and make sense of the contents). By the way, what does your stacktrace code do when it fails - prints nothing, prints garbage, hangs, crashes...?

You should at least have a look at the disassembly of your stacktrace code to see what it actually does. To safely read EBP, you should rather write a function in pure assembler and call it from your C code.

The failed output is in the image in the GH issue [0x0] S and a VGA whitespace.

And for that separate assemlby function, I'd just do and store ebp in eax then and ret?

Hi,

makerimages wrote:So, I've been at this for a while now - I've got a invalid opcode error somewhere and now I need a stacktrace to make sure, where it is. But.. my stacktrace code
refuses to work with me. I've tried every reasonable and unreasonable thing to fix this, to no luck. I'm starting to have thoughts of rewriting the OS completely. Perhaps any1 of you can be of help? https://github.com/makerimages/OSZin/issues/6

Stack traces only work for "specially crippled" code (specifically, code that uses slow C calling conventions even when it's not required for external linkage). The CPU's exceptions do not use C calling conventions; so (even when you fix the bugs) it'd still only give you a stack trace for things that happened after the exception occured and won't (correctly) show things that happened before the exception handler was started.

To work around that you need to change it to "void elf_printStackTrace(void *startingEBP) {..." and pass the value that was in EBP before the exception occurred. However; in that case (eventually, e.g. after you start supporting normal processes if you don't support that already) the code that could've caused the exception may have been anything (including raw assembly and/or something compiled with "-fomit-framepointer" that was running in user-space at CPL=3); and you'd also (eventually) want to provide some way to determine if the code that crashed is "specially crippled" or not (so you don't end up displaying complete nonsense because EBP was being used for something useful and not being used for the frame pointer).


Cheers,

Brendan

Apart from Brendan's concerns (which are, of course, correct) - if you really need to get the current value of EBP, the assembly should rather look like this: But as Brendan pointed out, this method will work only under very particular circumstances.

Aha, thanks for clarifying that. So given te circumstances that is actually valid output... I'll try to get some stacktracing with this code going somewhere else, to see wheter or not that gives anything. Then I'll look into the asm calling.

Sorry for the doublepost, but I now implemented that ASM thingy, and commented out the faulty code, to test the stacktrace normally. I kprintf'ed the EBP's at various points in the stack trace function. Seems like it get's sth and then ebp goes to 0... Still gives the weird oneliner.
http://puu.sh/g3yQu/059d60f9c4.png

https://github.com/makerimages/OSZin/commits/master

makerimages wrote:Still gives the weird oneliner.

Does 0xf000:0xdb53 sound like a reasonable address for a BIOS interrupt handler?

Octocontrabass wrote:

makerimages wrote:Still gives the weird oneliner.

Does 0xf000:0xdb53 sound like a reasonable address for a BIOS interrupt handler?

Google says it does, yes... How wonderful, I'm stacktracing my BIOS

Perhaps you should update your kprintf function to not print null pointers. :p (Or maybe keep it that way, since they're so easy to identify?)

Octocontrabass wrote:Perhaps you should update your kprintf function to not print null pointers. :p (Or maybe keep it that way, since they're so easy to identify?)

Nah. If it gives something out - bad things are easier to discover. So now - how do I not trace the BIOS? :/ Stacktraces are a must nowadays and I'd really like this to work..