breakpoints

[Andrey Vul]

Is there a way to set breakpoints without relying on platforms /
compilers or relying on nasal demons?

By nasal demons, I mean this one-liner: void breakpoint() { *((char *)
NULL) = 0; }

 

[Keith Thompson]

Is there a way to set breakpoints without relying on platforms /
compilers or relying on nasal demons?

No. The C language has no concept of breakpoints; anything you do to
set one therefore has to be system-specific.

 

[user923005]

Is there a way to set breakpoints without relying on platforms /
compilers or relying on nasal demons?

By nasal demons, I mean this one-liner: void breakpoint() { *((char *)
NULL) = 0; }

The closest thing in the C language is:
abort();

You may also enjoy:
assert(0);

HTH

 

[Andrey Vul]

The closest thing in the C language is:
 abort();

You may also enjoy:
 assert(0);

HTH

Not really.
exit != enter debugger

 

[user923005]

Not really.
exit != enter debugger

Depends on your compiler. Both of these will take me right to the
spot with some of the compilers I use.

However, if you want something that is standard and guaranteed to take
you right to a spot in the code, then you will have a bit of a sticky
wicket, I think.

 

[Seebs]

Not really.
exit != enter debugger

Right, but see, there's no standard debugger AT ALL, so no interaction
with the debugger is standardized.

The breakpoint() trick is likely, the other thing you can do is just
set breakpoints where you want them. A good debugger can likely turn
specific points on and off automatically, etc.

-s

 

[James Kuyper]

Not really.
exit != enter debugger

I think you're missing the point. C doesn't provide any method for
entering the debugger, so the fact that neither abort() nor assert()
have that effect doesn't prevent them from being "the closest thing in
the C language". Both of them halt processing at the specified location,
which is the only aspect of a breakpoint which CAN be simulated within C
itself.

Finally, on some systems, all you have to do to examine the current
state of the program after a call to abort() is to load the 'core' file
which may have been created as a side-effect of the abort() call, into a
debugger, which again makes this "the closest thing in the C language"
to setting up a break point.

 

[Rui Maciel]

Is there a way to set breakpoints without relying on platforms /
compilers or relying on nasal demons?

By nasal demons, I mean this one-liner: void breakpoint() { *((char *)
NULL) = 0; }

Why do you wish to use the breakpoints feature without the help of a debugger?


Rui Maciel

 

[jacob navia]

Andrey Vul a écrit :

Is there a way to set breakpoints without relying on platforms /
compilers or relying on nasal demons?

By nasal demons, I mean this one-liner: void breakpoint() { *((char *)
NULL) = 0; }

In the x86 type machines you can insert a breakpoint
instruction (int 3) in the code

typedef void (*voidfn)(void);
void breakpoint(void)
{
// int 3 is 0xcc
char * code = "\xcc";
voidfn fn = (voidfn)code;
fn();
}

This supposes that your operating system calls a registered debugger when it sees
an int 3.
In other CPUs that have a breakpoint instruction you can change the opcode.

Another (more portable) way is:

void breakpoint(void)
{
fprintf(stderr,"Breakpoint reached. Calling the debugger\n");
fflush(stderr);
system("My Path To The debugger with appropiate parameters\n");
}

This supposes that your debugger can attach to a running process. Most
debuggers do.

 

[Michael Schumacher]

Not really.
exit != enter debugger

Ah, that makes things clearer. There's no "standard" way whatsoever
to call a debugger from compiled C code, but provided your program
runs under control of a debugger (or at least a monitor that talks
to a debugger), and you want the program control transferred to the
debugger at specific points, you can do this:

#ifdef CHECKPOINTS
static void checkpoint (void) { /* empty */ }
#define CHECKPT do { checkpoint (); } while (0);
#else
#define CHECKPT /* empty */
#endif

You should put this in a header file (say, "checkpt.h") and #include
it in all C modules where you want to apply checkpoints (of course,
you'll later have to recompile them with "-DCHECKPOINTS").

Then, insert "CHECKPT"s in your C code wherever you deem them right,
and set an actual breakpoint from within the debugger to "checkpoint"
(usually before you start the program). If your program hits such a
CHECKPT, the debugger will re-gain control, and you will have to use
its "one frame up"-command to set the context to the causing CHECKPT.
With gdb, you can easily automate this by attaching an "up" command
to the "checkpoint" breakpoint from within a command file (.gdbinit).

Since breakpoints (and breakpoint handling) depend on so many things
(monitor, debugger, target architecture, target OS, memory type and
memory protection, a.s.o.), I think this approach is the closest you
can get to "independent breakpoints". I'd really appreciate it if
someone could prove me wrong on this, but I doubt this will actually
happen... ;-)


Cheers,
mike

 

[Keith Thompson]

Andrey Vul a écrit :

In the x86 type machines you can insert a breakpoint
instruction (int 3) in the code

typedef void (*voidfn)(void);
void breakpoint(void)
{
// int 3 is 0xcc
char * code = "\xcc";
voidfn fn = (voidfn)code;
fn();
}

This supposes that your operating system calls a registered debugger
when it sees an int 3. In other CPUs that have a breakpoint
instruction you can change the opcode.

Another (more portable) way is:

void breakpoint(void)
{
fprintf(stderr,"Breakpoint reached. Calling the debugger\n");
fflush(stderr);
system("My Path To The debugger with appropiate parameters\n");
}

This supposes that your debugger can attach to a running process. Most
debuggers do.

I don't believe this answers the question. He specifically asked for
"a way to set breakpoints without relying on platforms / compilers or
relying on nasal demons". Your methods are extremely system-specific.

Would you really use the techniques you suggest? Or, if you have a
debugger, would you just run the program under the debugger and use
the debugger to set a breakpoint?

I suppose the difference is that the program can invoke the debugger
conditionally, say, if it reaches some "this should never happen"
state.