3 ms·

I sprinkle printf's OR use my 'xlog' logging function which can be configured to use more restricted parameters. Mainly I use the 'xlog' function. I can then w

I sprinkle printf's OR use my 'xlog' logging function which can be configured to use more restricted parameters. Mainly I use the 'xlog' function. I can then wander about the logging file (using a text-editor for navigation) looking at various 'befores' and 'afters'. I use a bit-mapped variable 'debug' which allows or disallows the logging statements accordingly. For example, in an emulator, with debug only configured for floppy-disk-controller logging, and looking at the floppy-disk controller code, we might see: xlog (FDC, "sdma_getdatareg: disk_data: fd_byte_ptr:%04X bytes_to_xfer= %4X data:%02X\n", fdcd->fd_byte_ptr, fdcd->bytes_to_xfer, data); which would be logged, and xlog (INFO, "RESETTING %s\n", MACHINE_NAME); which would not. As for using 'gdb', I tend to use that only when I have no clue, or a wrong clue, where the code is breaking down. I tend to leave the logging code around if it's not particularly obstructive or long-winded as I can switch it out at will by setting 'debug' to zero.

EvanAnderson 5y ago
I really like when software uses this technique and leaves the logging present in release code. As a sysadmin being able to crank up debugging logs is nearly as useful as source code access if the developer has been thorough with their logging calls. Seeing internal state goes a long way toward figuring out whys seemingly-correct configuration isn't actually doing what you want.
pjmlp 5y ago
I can do the same in the debugger without changing one line of production code thanks to tracepoints, and breakpoint actions.
- simonblack 5y ago
  Yes you can, but you need to be pro-active about what you want to know when using gdb (etc.) that way. Logging gives a solid background of stuff you may not have thought about specifically. It is often the first clue that 'something is rotten in the state of Denmark' when the values that show up are not what they should be. In truth, debugging is a detective-story, and anything that helps, be it debuggers or logging or printf, is grist for the mill.
  - pjmlp 5y ago
    Most of the logs I see in production are useless garbage because the coder did not thought of what is relevant. With a debugger I can place the probes and do my own printfs instead.
    - simonblack 5y ago
      <grin> It's not one or the other. You are free to use both, logging and a debugger.

EvanAnderson 5y ago

I really like when software uses this technique and leaves the logging present in release code. As a sysadmin being able to crank up debugging logs is nearly as useful as source code access if the developer has been thorough with their logging calls. Seeing internal state goes a long way toward figuring out whys seemingly-correct configuration isn't actually doing what you want.

pjmlp 5y ago

I can do the same in the debugger without changing one line of production code thanks to tracepoints, and breakpoint actions.

simonblack 5y ago
Yes you can, but you need to be pro-active about what you want to know when using gdb (etc.) that way. Logging gives a solid background of stuff you may not have thought about specifically. It is often the first clue that 'something is rotten in the state of Denmark' when the values that show up are not what they should be. In truth, debugging is a detective-story, and anything that helps, be it debuggers or logging or printf, is grist for the mill.
- pjmlp 5y ago
  Most of the logs I see in production are useless garbage because the coder did not thought of what is relevant. With a debugger I can place the probes and do my own printfs instead.
  - simonblack 5y ago
    <grin> It's not one or the other. You are free to use both, logging and a debugger.