breakpoints

Discussion in 'C Programming' started by Andrey Vul, Oct 27, 2009.

  1. Andrey Vul

    Andrey Vul Guest

    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; }
     
    Andrey Vul, Oct 27, 2009
    #1
    1. Advertising

  2. Andrey Vul <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Oct 27, 2009
    #2
    1. Advertising

  3. Andrey Vul

    user923005 Guest

    On Oct 26, 5:26 pm, Andrey Vul <> wrote:
    > 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
     
    user923005, Oct 27, 2009
    #3
  4. Andrey Vul

    Andrey Vul Guest

    On Oct 26, 8:35 pm, user923005 <> wrote:
    > On Oct 26, 5:26 pm, Andrey Vul <> wrote:
    >
    > > 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

    Not really.
    exit != enter debugger
     
    Andrey Vul, Oct 27, 2009
    #4
  5. Andrey Vul

    user923005 Guest

    On Oct 26, 7:03 pm, Andrey Vul <> wrote:
    > On Oct 26, 8:35 pm, user923005 <> wrote:> On Oct 26, 5:26 pm, Andrey Vul <> wrote:
    >
    > > > 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

    >
    > 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.
     
    user923005, Oct 27, 2009
    #5
  6. Andrey Vul

    Seebs Guest

    On 2009-10-27, Andrey Vul <> wrote:
    > 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
    --
    Copyright 2009, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Oct 27, 2009
    #6
  7. Andrey Vul

    James Kuyper Guest

    Andrey Vul wrote:
    > On Oct 26, 8:35�pm, user923005 <> wrote:
    >> On Oct 26, 5:26�pm, Andrey Vul <> wrote:
    >>
    >>> 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

    > 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.
     
    James Kuyper, Oct 27, 2009
    #7
  8. Andrey Vul

    Rui Maciel Guest

    Andrey Vul wrote:

    > 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
     
    Rui Maciel, Oct 27, 2009
    #8
  9. Andrey Vul

    jacob navia Guest

    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.
     
    jacob navia, Oct 27, 2009
    #9
  10. Andrey Vul wrote:

    > On Oct 26, 8:35 pm, user923005 <> wrote:
    >> On Oct 26, 5:26 pm, Andrey Vul <> wrote:
    >>
    >> > 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

    > 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
     
    Michael Schumacher, Oct 27, 2009
    #10
  11. jacob navia <> writes:
    > 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.


    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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Oct 27, 2009
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Doug Swanson
    Replies:
    5
    Views:
    2,049
    Doug Swanson
    Jul 28, 2003
  2. Ron Icard

    ASP.NET ignoring all breakpoints

    Ron Icard, Aug 22, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    449
    Ron Icard
    Aug 22, 2003
  3. Brent Burkart
    Replies:
    0
    Views:
    435
    Brent Burkart
    Oct 27, 2003
  4. Dave

    VS.net breakpoints

    Dave, Dec 4, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    705
    Jose Luis Rodriguez
    Dec 4, 2003
  5. Shawn South
    Replies:
    0
    Views:
    3,441
    Shawn South
    Aug 16, 2004
Loading...

Share This Page