OSDev.org

Hi,

If I compile my kernel with debug symbols with GCC ( -g option), will they be present in the linked executable if I link it to a flat binary? Or do I have to use ELF?

Because when I compile my kernel to a flat binary with debugging symbols, the file size remains the same...

Since your question follows the exact format as one of the examples from the smart questions rule, I'll honour your attempt by quoting the associated answer.

Eric S. Raymond wrote:Try it and see. If you did that, you'd (a) learn the answer, and (b) stop wasting my time.

I don't think you have ever helped me. All you do is piss me off.

I have tried it (you would have realised this had you actually read the original post properly), but I don't know if the debugging symbols were included or not, because the file size remained the same (you would also have realised this if you read the original post properly). The file size not changing might mean that the debugging symbols were not included, however it could be to do with padding (the debugging symbols simply use up some of the space that would otherwise be padded).

Anyone got anything helpful to say?

EDIT: After further inspection, I believe that debugging symbols are removed when converting to flat binary... how do I debug a flat binary then?

Hi,

BMW wrote:EDIT: After further inspection, I believe that debugging symbols are removed when converting to flat binary... how do I debug a flat binary then?

You can create an ELF file, extract information from it (e.g. with "objdump" or "nm"), then convert that ELF file into flat binary. Then (when debugging) you can figure out which addresses correspond to what using the information you extracted.

Alternatively you can use macros to add your own debugging information to the flat binary. For example, one of the things I did in my earlier kernels was to have a "MARK" macro that stores a magic signature (e.g. 0xCC90CC90), a line number, file name and another magic signature (0x90CC90CC) in the binary; and before each routine I'd add this "MARK" to it. Then I added special handling in my kernel's exception handlers to search backwards starting from exception's "return CS:EIP" to find the previous mark and display the file and line number. The end result was that I could quickly find the routine that contained that code that crashed (and use the register dump and a disassembly to find the instruction that crashed). Of course it doesn't take much thought to do something a lot better than this (like putting the information in its own section).

Finally, I wouldn't be too surprised if it was possible to tell the linker to put the debugging symbols into the flat binary. The problem here is that it won't help unless you've got something that can find/use those debugging symbols.

I'd also point out that I normally use assembly, so (e.g.) Bochs debugger shows me something that looks very similar to my source code. For high level languages a disassembly looks nothing like your source code, so debugging is more painful.


Cheers,

Brendan

Brendan wrote:Hi,

BMW wrote:EDIT: After further inspection, I believe that debugging symbols are removed when converting to flat binary... how do I debug a flat binary then?

You can create an ELF file, extract information from it (e.g. with "objdump" or "nm"), then convert that ELF file into flat binary. Then (when debugging) you can figure out which addresses correspond to what using the information you extracted.

Alternatively you can use macros to add your own debugging information to the flat binary. For example, one of the things I did in my earlier kernels was to have a "MARK" macro that stores a magic signature (e.g. 0xCC90CC90), a line number, file name and another magic signature (0x90CC90CC) in the binary; and before each routine I'd add this "MARK" to it. Then I added special handling in my kernel's exception handlers to search backwards starting from exception's "return CS:EIP" to find the previous mark and display the file and line number. The end result was that I could quickly find the routine that contained that code that crashed (and use the register dump and a disassembly to find the instruction that crashed). Of course it doesn't take much thought to do something a lot better than this (like putting the information in its own section).

Finally, I wouldn't be too surprised if it was possible to tell the linker to put the debugging symbols into the flat binary. The problem here is that it won't help unless you've got something that can find/use those debugging symbols.

I'd also point out that I normally use assembly, so (e.g.) Bochs debugger shows me something that looks very similar to my source code. For high level languages a disassembly looks nothing like your source code, so debugging is more painful.


Cheers,

Brendan

Well, the kernel triple faults the CPU before I can load the IDT, so I can't use the kernels exception handlers.

I did some testing, and discovered that if I remove some unused code, resulting in a smaller kernel, it works. The problem must be to do with the loading of the kernel or something...

BMW wrote:I don't think you have ever helped me. All you do is piss me off.
(...)
EDIT: After further inspection, I believe that debugging symbols are removed when converting to flat binary...

You're only pissed off because you're hearing a truth you don't want to hear, and in this case you're simply refusing to realize you never needed that help. Especially, it is only your fault that this is one more of those threads where you ask a different question than the actual problem you are facing.

So did you waste our time with that first post? Yes. Call me a gayboy again if you want, then edit it out before the staff comes to see it - the only reason I'd care is that it merely proves your lack of attempt to stick to any of the forum rules we have here. And for that matter, feel free to actually piss off because not posting means not being able to break the mentioned forum rules.

One thing I learned about this job is that it requires the utmost amounts of self-sufficiency. Documentation is in surplus amounts available, especially at the level where you are now. People only fail because of their lack of skill, which makes training that my first priority. And since you obviously refuse to take any such advice, you're only having yourself to blame it in the end.



tl;dr: Since you answered your own question in part or whole two times in a row now this thread, go on answer your last one as well. You can do it!

There's nothing to stop you creating an elf object file and a binary file from the same makefile. Then you can start debugging your binary in qemu and load the symbols from the elf file (with the command "file filename.o"). That way, although you are running the flat binary you can still use all the debugging information. I'm sure there are other ways to do it, but that works for me.

As an aside to the ("try it and see" school of thought - of which I am a strong believer), tell the linker to produce a map file. Then you will be able to see exactly what is in the finished linked file. Not only that, but you'll know at exactly which location various functions and variables are situated. Also, have a play with "objdump" on a few object files and linked elf executables. Try it and see" requires you to understand your tools; if that was the only thing it encouraged it would be a useful exercise.

I've got to agree with others that you are asking some very basic questions here that you really should be able to discover the answers to by yourself. If not then perhaps you need to learn a little more general programming before getting too deep into the complicated stuff. It's not necessary (or possible) to know everything but you should at least strive to learn how to find the answers. That doesn't mean just asking someone else all the time; save that for the really difficult questions and people will be more sympathetic.

Combuster wrote:

BMW wrote:I don't think you have ever helped me. All you do is piss me off.
(...)
EDIT: After further inspection, I believe that debugging symbols are removed when converting to flat binary...

You're only pissed off because you're hearing a truth you don't want to hear, and in this case you're simply refusing to realize you never needed that help. Especially, it is only your fault that this is one more of those threads where you ask a different question than the actual problem you are facing.

So did you waste our time with that first post? Yes. Call me a gayboy again if you want, then edit it out before the staff comes to see it - the only reason I'd care is that it merely proves your lack of attempt to stick to any of the forum rules we have here. And for that matter, feel free to actually piss off because not posting means not being able to break the mentioned forum rules.

One thing I learned about this job is that it requires the utmost amounts of self-sufficiency. Documentation is in surplus amounts available, especially at the level where you are now. People only fail because of their lack of skill, which makes training that my first priority. And since you obviously refuse to take any such advice, you're only having yourself to blame it in the end.



tl;dr: Since you answered your own question in part or whole two times in a row now this thread, go on answer your last one as well. You can do it!

Ok lol, I am sorry for being a *****. Good advice.

iansjack wrote:There's nothing to stop you creating an elf object file and a binary file from the same makefile. Then you can start debugging your binary in qemu and load the symbols from the elf file (with the command "file filename.o"). That way, although you are running the flat binary you can still use all the debugging information. I'm sure there are other ways to do it, but that works for me.

As an aside to the ("try it and see" school of thought - of which I am a strong believer), tell the linker to produce a map file. Then you will be able to see exactly what is in the finished linked file. Not only that, but you'll know at exactly which location various functions and variables are situated. Also, have a play with "objdump" on a few object files and linked elf executables. Try it and see" requires you to understand your tools; if that was the only thing it encouraged it would be a useful exercise.

I've got to agree with others that you are asking some very basic questions here that you really should be able to discover the answers to by yourself. If not then perhaps you need to learn a little more general programming before getting too deep into the complicated stuff. It's not necessary (or possible) to know everything but you should at least strive to learn how to find the answers. That doesn't mean just asking someone else all the time; save that for the really difficult questions and people will be more sympathetic.

Of course, thanks!!!

And thanks for the other advice , I'll try to use it this time.

Ok... I set a breakpoint at the kernel entry, and it didnt break. Great, it doesn't even get to the kernel entry.

So my suspicion now is that the kernel is not being loaded properly.

Is there any way I can do a memory dump in QEMU(dump the memory of the emulated computer) when it triple faults or something?

I am beginning to lose my patience at your inability to RTFM, so this is the last time I am going to answer one of your questions. I think you are not ready for this sort of development if you are unable to research and read documentation.

http://en.wikibooks.org/wiki/QEMU/Monitor