Page 2 of 3
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 7:50 am
by Solar
I cannot talk about driver development, but on the application level...
rdos wrote:Solar wrote:Another part of the skill involved. Your log statements should not have side effects, and your code should be stable enough not to react to stuff like compiler-introduced reorderings (a.k.a. "if I enable optimization my code breaks").
If the code debugged depends on timing, any insertion of code of whatever triviality might change the behavior. Printf is just a major distrurber because it takes time to execute.
...code that "depends on timing" like that is broken, period.
It is a little hard to do unit testing for hardware-device-drivers meant for an OS.
That's what I said: Choose the appropriate tool for the task at hand. Sometimes it's GDB, sometimes printf(), and most of the time (but not always) you should've written a unit test in the first place.
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 8:09 am
by AJ
Solar wrote:...code that "depends on timing" like that is broken, period.
What if I'm trying to write some complex control code for my atomic clock?
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 8:23 am
by rdos
AJ wrote:Solar wrote:...code that "depends on timing" like that is broken, period.
What if I'm trying to write some complex control code for my atomic clock?
Yes, or what about if the AHCI HBA posts ready-requests to the OS before the data is physically transfered? Or if the device-driver uses the incorrect algorithm to know when data is available? Most hardware-device communication that is layed-out in physical memory using DMA busmasters is like this, and this is common in modern NICs / USBs and disc implementations. A simple printf could be the difference between working / not-working.
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 8:28 am
by Solar
Solar wrote:I cannot talk about driver development, but on the application level...
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 8:47 am
by rdos
Solar wrote:Solar wrote:I cannot talk about driver development, but on the application level...
Interestingly, I've validated our terminal applications on RDOS at least 5 years prior to the first installation that actually runs RDOS itself. I did this because I didn't like the idea of "printf"-debugging, as this was the only means of debugging on V25-based hardware. And porting the terminal to Windows didn't work very well as Windows lacked critical functionality (exact waits and decent thread-scheduling policies).
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 8:55 am
by harvey
I'm eager for a kernel debugger, because in the booting time, especially in real mode, I haven't finished a log function like printk.
Your replies really open my mind.
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 9:04 am
by SDS
rdos wrote:If the code debugged depends on timing, any insertion of code of whatever triviality might change the behavior. Printf is just a major distrurber because it takes time to execute.
To be honest, the worst type of these bugs is where different threads are interacting with each other (race conditions etc.). Both printf debugging, and single stepping threads will move/hide these bugs. As may just running the code again.
That said, both printf and single-step debugging are essential in different circumstances.
Most of the code I write is computational chemistry code, and often the place where a bug shows up (where you notice a numerical discrepancy) is very different to what caused a slight numerical slip, which may be very deeply hidden far from any data output. I find stepwise debugging here next to useless, as generally all of the sections of the code seem to be doing something reasonable - and even isolating which bit to step through is not easy in 70000 odd lines of code. Careful use of printf statements to check consistency between elements of input and output of different sections is far easier to isolate the problem to a section - and then the bug is often obvious to inspection, not needing single-stepping line by line. Lines of code do tend to do what they say they will, after all...
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 11:40 am
by Combuster
rdos wrote:A simple printf could be the difference between working / not-working.
Solar wrote:code that "depends on timing" like that is broken, period.
Point in case: If your driver can't even handle the latency of a print function, it can't handle the latency of several interrupts firing simultaneously either.
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 12:16 pm
by rdos
Combuster wrote:rdos wrote:A simple printf could be the difference between working / not-working.
Solar wrote:code that "depends on timing" like that is broken, period.
Point in case: If your driver can't even handle the latency of a print function, it can't handle the latency of several interrupts firing simultaneously either.
That was not the point. By inserting the printf-code, the code would
work, and when it is removed it would fail.
OTOH, I could envision a NIC-driver that would do the opposite under heavy traffic. With too much logging, buffers would overflow, and the NIC-driver would fail with loggings but not without.
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 2:31 pm
by gerryg400
RDOS, of course it's okay (sometimes) to use a kernel debugger to step your code. In fact you need lots of different debugging techniques. I think you mentioned that sometimes you use segmentation to debug software. The point of my original reply was that it's not necessary to use GDB to debug. And I stand by that. Especially with something simple like boot code that generally runs a linear sequence of code with no timing issues.
Re: Why GDB can't work properly when debugging real mode cod
Posted: Wed Nov 02, 2011 4:28 pm
by rdos
For boot code, I'd use an emulator. Back in the days when I did this, I had my own processor-emulator. Today we have emulators that are useful, so there is no need in writing one yourself.
Re: Why GDB can't work properly when debugging real mode cod
Posted: Fri Nov 04, 2011 7:11 am
by harvey
Good news!!! My codes have finished the real mode work and enabled the paging. And I find since the OS transfers from the real mode to protected mode with paging enabled, the GDB has worked properly as I expected. Especially, "print xxx" and "backtrace" commands print correct results when debugging C codes.
Re: Why GDB can't work properly when debugging real mode cod
Posted: Fri Nov 04, 2011 2:22 pm
by Combuster
berkus wrote:What is the reason for calling them codes? Is it nowadays popular on the internets?
Typical for a speaker that hasn't seen and used the word "code" often enough to realize its uncountable (and therefore has a 90% chance that the person in question lacks the experience to post here. This thread being no exception)
Re: Why GDB can't work properly when debugging real mode cod
Posted: Mon Nov 07, 2011 5:17 am
by SDS
This also appears to be in common usage for computational science (at least in the department here). For example;
I have a code which can calculate ...
... research group has several codes to calculate x and y.
Re: Why GDB can't work properly when debugging real mode cod
Posted: Mon Nov 07, 2011 5:33 am
by Combuster
Show me teh codez,
how professional.