Author Topic: capturing gdb command line output  (Read 8067 times)

SoftJunkie

  • Community Member
  • Posts: 32
  • Hero Points: 1
capturing gdb command line output
« on: July 30, 2007, 07:52:59 pm »
i would like to capture the call stack when i assert somewhere in my code. i can use the 'debug-send-command backtrace' command from the slick border command line but it displays the output to a dialog box. is it possible to send the result to a file (or better yet, a buffer) so that i can copy and paste this info to an e-mail?

SoftJunkie

  • Community Member
  • Posts: 32
  • Hero Points: 1
Re: capturing gdb command line output
« Reply #1 on: August 01, 2007, 12:39:41 pm »
bump

StephenW

  • Senior Community Member
  • Posts: 189
  • Hero Points: 21
Re: capturing gdb command line output
« Reply #2 on: August 01, 2007, 09:11:42 pm »
Stack dumps are automatically appended to your vs.log file.  In Windows, this is in your

  <bootdrive>:\Documents and Settings\<userid>\My Documents\My SlickEdit Config\12.0.2\

directory.

hs2

  • Senior Community Member
  • Posts: 2737
  • Hero Points: 288
Re: capturing gdb command line output
« Reply #3 on: August 01, 2007, 10:58:33 pm »
This is right for Slick-C stack dumps getting stored in VSLICKCONFIG dir, but SoftJunkie talks about call-stack backtraces provided by gdb when debugging a target executable.
HS2

StephenW

  • Senior Community Member
  • Posts: 189
  • Hero Points: 21
Re: capturing gdb command line output
« Reply #4 on: August 01, 2007, 11:49:12 pm »
OK, now I understand the problem.  I took a look at the debug_send_command macro in debug.e, and it is a pretty simple one.  It looks as though it could be copied as a custom macro (eg debug_send_command_and_log_result) and just replacing the line:

  _message_box(reply:+errmsg,command);

with something that stored to a file or buffer would do what is wanted.  Maybe something like:

  edit("debug_output.log");
  bottom_of_buffer();
  insert_text(reply:+errmsg);
  save();

Which, if I have it right, would append the command results at the end of the debug_output.log file.  I do not use gdb, so I have not tested this at all.

SoftJunkie

  • Community Member
  • Posts: 32
  • Hero Points: 1
Re: capturing gdb command line output
« Reply #5 on: August 02, 2007, 05:28:27 pm »
thanks for the responses. i've never spent any time in creating or modifying a slick macro. i'll try your solution.

StephenW

  • Senior Community Member
  • Posts: 189
  • Hero Points: 21
Re: capturing gdb command line output
« Reply #6 on: August 02, 2007, 10:51:59 pm »
If you are doing SlickEdit macros for the first time, I would recommend setting up a separate directory for your custom macros, rather than putting them with the SlickEdit setup.  I have mine at:

  C:\Documents and Settings\<userid>\My Documents\My SlickEdit Config\custom

which is just above the directory where SlickEdit stores its configuration files:

  C:\Documents and Settings\<userid>\My Documents\My SlickEdit Config\12.0.2

Keeping them separate keeps them out of the way when you update SlickEdit - no worries that something might go wrong and cause them to be deleted.  And when SlickEdit changes version number, the directory they are stored in does not move, and you do not have to update where the files are.

I have a workspace and project ("Customising SlickEdit") set up for the macros I have there.

If you are intending to run the "debug_send_command_and_log_result" macro from the command line rather than attaching it to a keystroke, I would recommend choosing a short name for it (eg "dscl"), or better yet, giving it that name as an alternative:

  _command int debug_send_command_and_log_result, dscl (_str command='') name_info(','VSARG2_EDITORCTL|VSARG2_REQUIRES_MDI|VSARG2_READ_ONLY)
  {

SoftJunkie

  • Community Member
  • Posts: 32
  • Hero Points: 1
Re: capturing gdb command line output
« Reply #7 on: August 02, 2007, 10:55:09 pm »
thanks for the tips. any and all are appreciated! where is the best source of info for understanding macros? is there a 'hello world' tutorial?

hs2

  • Senior Community Member
  • Posts: 2737
  • Hero Points: 288
Re: capturing gdb command line output
« Reply #8 on: August 02, 2007, 11:25:23 pm »
Check the <SE install-dir>/docs/SlickCMacroBestPractices.pdf  and ~/Slick_C_Macro_Programming.pdf.
They are pretty good.

HS2

StephenW

  • Senior Community Member
  • Posts: 189
  • Hero Points: 21
Re: capturing gdb command line output
« Reply #9 on: August 02, 2007, 11:32:41 pm »
I am afraid that there is no really easy way to get started with writing macros from scratch - Slick-C is, after all, a full scale programming language, with a massive library of existing routines to get familiar with.  Fortunately your need is rather easier, as it involves just copying and modifying an existing macro, so you do not really have to dive in the deep end and learn everything at once.  For example, you can ignore all the "name_info" stuff, as it is already correctly set in the macro you are copying.

There is a tutorials section in the help file "Slick-C® Macro Programming Guide" section, which you should have look at.  But eventually if you want to write macros you will need to read the entire "Slick-C® Macro Programming Guide".  It is also very useful to use the macro recorder to do things and then see what code was used to do them - see "Macros and Macro Programming" in the main part of the help file.  I would also recommend reading the front of the "Slick-C® Macro Programming Guide" before too long, as far as the section "Preprocessing".  That will give you the basics of the language, and how it is similar to and differs from C++, without going into all the details about GUI programming.  I have managed to avoid having to learn the GUI stuff so far!

If anything goes wrong, you will need to know about "messageNwait", "message" and "say" which are the principle debug output methods - look them up in the helpfile.

It would not hurt at all to just dive in and copy debug_send_command, do the edits and see what happens.  It might just all work, as this is a reasonably simple macro.