How do you tell which code you're looking at when you display a machine instruction at your breakpoint? Is it the compiler's generated code or yours?
The compiler supplier is doing the job. Part of the job is fix the bugs the customers reported. There is no such thing as a perfect program.
/BAH
then don't believe it; you won't learn anything either.
No. We shipped what had to be supplied.
Splutter....[emoticon wipes of TTY screen] No.
Computer usages haven't changed and code is only code. The situation remains the same. As I stated, the reason Linux is successful is because the sources are available to anybody who wants to use them or needs to use them.
Wonderful...now you have lots of code which can break if your workaround no longer works when the bug is fixed.
this has nothing to do with design. For compiler design, read the standard.
Yes, we did.
No because we put the fixes in the sources.
yes.
Yes. We had to.
Since you need the bug fixed, it is also becomes your problem.
/BAH
I know BAH is right. I wuz there too, though on the opposite (winning) side of that war. ;-)
You wouldn't like the benefit of the knowledge of rest of the world?
Obviously you're too full of yourself to benefit from the work of others. Be happy with M$. You deserve each other.
On any debugger worth it's salt, you'll see the machine instruction as pulled from the target.
But perhaps I don't understand your question.
-- Les Cargill
But which target? If you're debugging a user mode program which calls in libraries or uses intrinsic functions, how do you tell where the machine instruction came from? You are stopped at a breakpoint which was set in your code but if you do an $X (the debugger I used would execute the next instruction with that command), how do you know it's from your code and not from a library or somewhere else?
Note that I'm assuming the compiler you used fixed up all the code, including providing all the library code that was referenced.
Note that I've never debugged an Intel-isk machine.
Was that written more clearly for you? If not, I'll try again tomorrow.
/BAH
Yah. [emoticon waves virtual baseball bat /\\/\\/\\] take that. ;-)
/BAH
Whatever machine your code is running on. I mean "host" to mean where you built it, "target" to mean the machine you're running on. This could be the same machine - mostly, I come from embedded systems where they are not.
By analyzing the address - you need mixed source/object listings. Any given address will come either from your code or from library code.
Most debuggers have a source view, an assembly-only view and a mixed-listing view. Most compilers/linkers/locaters provide a way to produce mixed listings and map files.
Most debuggers also provide a stack view - who called whom to get to where the program counter is now. They also allow you to single-step ( what the $X command does ) in assembly or source mode.
The principles are the same on a Mac - assuming your Mac isn't also Intel.
I think so :)
-- Les Cargill
In modern debuggers you can see the source code at the same time with the instructions. It's quite easy to read what file is opened in the debugger. Also stack traces tell the call paths etc. And if the source code information is not available, at least the function name and library is usually visible (or in some commercial sw mangled function name, that the support can figure out).
Or used debugger in last 30 years? The modern debuggers are quite similiar for different platforms (arm, x86, ppc etc.).
--Kim
So today's compilers never put library code in the user mode program's address space? At some things haven't changed :-).
ah, Ok.
Can you single-step from the monitor's POV? By monitor, I mean what you Unix guys call the kernal.
I've lost track of gear. I haven't debugged on these new-fangled machines.
Oh, good. I had no idea how to rewrite it :-)).
/BAH
Those debuggers must take up a lot of address space.
Last time I debugged at machine code level was around 1987. Not quite 30 years. ;-)
/BAH
Not that I have seen. Never say never.
Maybe. But not really. Er, at least I haven't seen anything but JTAG debuggers in a long time. Those will allow you to adapt the frame of reference of the kernel, but it's not like it was with a bonded-out emulator.
-- Les Cargill
The dynamic linker "links" the code together at start time. And after that it is known where all the different pieces of the code reside in the address space of that particular program.
Binaries are not usually statically linked anymore. The library code is taken into use when the program is started, and also the library code can be updated and after that each binary uses the new library code (or the old one, depending on the configuration).
Yes, depending on the tools and the OS. Most of the other processors than x86 support debuggers that control the HW via JTAG connection and they can be used to debug the kernel as it would be normal code, even SW TLB fill routines can be seen usually etc. For x86 the OS can build kernel mode debugger support, for example Linux has kernel mode debugger support.
But even today you might sometimes need all kinds of hacks to debug really nasty problems. My favourite has been PCI bus analyzer triggering processor emulator and stopping the code via PCI protocol errors ;)
--Kim
Do you realize how much this makes me shudder? ;-)
Oh, I'm not talking about debugging the kernel but debugging the user mode program by placing a breakpoint in the kernel and then single-stepping. Don't you do this? It can be quite useful.
The one hack that hasn't been reinvented is address break. When that happens, you will have lots of fun and success (instead of sweating blood and tears).
/BAH
Why would you place breakpoint to kernel if you are debugging user space program. If you are debugging user space program the debugging can be handled there, you can just as well place breakpoints etc. If you are debugging kernel you use different tools. Or if you are trying to debug system calls made by the userspace it can be also done with ICE debuggers for example. You just enable that they can follow the code to protected kernel address space. And then there is usually libraries between the kernel and userspace, kernel is seldom called directly from user mode programs.
What do you mean by address break. In modern terminology that usually is the normal breakpoint in code, attached to some certain instruction pointer value which breaks execution. This is supported by almost all processors in use. If you meant data breakpoint, which means that write to a certain address triggers break that is called data breakpoint, and is supported also by many processors.
--Kim
BEcause I also wrote kernel code to support the user space program. Because it's a learning experience to find out what the kernel does in behalf of the user mode program. Because I can.
Not if you have a really pesky bug which seems to defy the physical laws. There are times when debugging from the user mode point of view changes memory arrangements just enough that you can't trip the bug. Then you put a breakpoint in the monitor (our name for your kernel) and run the user mode program with all the "extras" that get put in when debugging it.
It should never be but always go through a "gatepost".
We could set an address break on read, write and also declare a mask. No processors, that I'm aware of, provide the hardware to use it. This feature, AFAIK, is not implemented anywhere.
/BAH
You are out of date. Intel P4 provides break on read or write access to memory address range or I/O ports with a length mask. See for example chapter 19 in
Few commercial debuggers exploit these hardware facilities or the perfomance tuning counters but the P4 hardware implements them.
Regards, Martin Brown
In comp.dsp jmfbahciv wrote: (snip)
As someone mentioned, Intel does.
IBM did it on S/370 before that, and it should still be there on S/390 and z/Architecture. Very useful for debuggers. The ORVYL debugger used it, I haven't seen any since, but then I haven't looked very hard.
-- glen
That is very uncommon way of debugging, usually the userspace programmer only looks into the system call or c-library API, and checks if that works as expected. But still debugging the kernel at the same time can be done, and have been done for a long time.
And how many application programmers even know enough of the kernel to debug it. The kernel is millions of lines of code. It's easier just to check that the boundary to the kernel works as expected. And if it doesn't someone else can debug from there.
No, the memory arrangement does not change when debugging from userspace. Maybe it did at some point of time, not anymore.
You should not state things like that, if you really don't know anything about processors of today. What processors do you know, just for future reference? Just as an example, the e300 PPC core which is very common in embedded applications has two instruction address breakpoints and two data address breakpoints (trap from R,W or R+W) in HW. In ARM I think data address breakpoints are called watchpoints, but they are supported also. And ARM is the most common processor on this planet.
All modern Intel processors have even broader support (masks etc.). Also different processors have all kinds of performance counters that can be used for debugging.
--Kim
It wasn't in my world ;-). I find your method restrictive.
That's one of the problems in the biz these days, IMO.
All code runs with the debugger in memory?
Now I'm aware.
Old stuff. PDP-nn
So you can get a breakpoint when a particular bit in a specified byte in memory is cleared or set?
/BAH
It is, and it ain't. You're better off knowing, but that may or may not be the most economic approach.
Depends on the debugger. For JTAG-connected devices, you can run with almost zero debugger footprint.
No, this is still out there - it just requires direct hardware support. The old HMI 68000 emulator we used during the Reagan administration :) had an arrangement of pulling an "interrupt" when certain masks were met on the bus. That "interrupt" stopped the processor directly - the HMI was a bonded-out-part emulator that you replaced the processor with.
What's available goes from that ( very excellent ) approach to ... less excellent. You could debug to the level you'd normally need a logic analyzer for with the HMI - I actually *beat* the logic analyzer a couple of times with the HMI ( it had more depth, and you could dump all the bus cycles off to a PC for very large-scale analysis to catch flakies ).
You can if that is offered as a hardware feature of the system in question. Not very frequently, I'm afraid - setting a bit in DDR2 involves a great many parts operating in harmony - it's not like jamming a signature on the pins of a SDRAM chip like the good old days :) And for all I know, PDP-nn may or may not have even used SDRAM. That may be before *my* time, even.
Instrumentation in stuff in general goes begging these days, unless you get good support for it from within the organization. That's not
100% bad - you have to incorporate that into planning at a higher level than you used to, but having to explain to people why they might need it can be frustrating.-- Les Cargill
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.