Kinda OT: Summoning the debugger on demand?

[Ramon F. Herrera]

A while back I was told of a way in which I can add one line of code
in MSVS which would cause the debugger to show up.

Is there an equivalent facility in gcc/gdb??

TIA,

-Ramon

[ralph]

This is a "feature" of the operating system and not part of the C/C++
language - except as a vendor/platform extension.
In Windows this accomplished by raising an "int 3".

Most POSIX systemS respond to ...
raise(SIGTRAP);

If I remember correctly gcc provides the extension ...
__builtin_trap() // raises SIGILL ??

If worse comes to worse you with a JIT Debugger enabled you can just
do something outragious such as divide by zero or reference a NULL
pointer. <g>

-ralph

[Geoff]

On Thu, 4 Apr 2013 10:17:28 -0700 (PDT), "Ramon F. Herrera"
<ra...@conexus.net> wrote:

>

The facility is invoked the same way in Linux as it is in Windows.

In Windows, call DebugBreak().


In GCC you can write your own:


void Sys_DebugBreak (void)
{
__asm ("int $3");
}

[Ramon F. Herrera]

Thanks Geoff!

I tried your (very useful) tip in Linux, but it seems that I am
missing something. My application (as a general rule) is a shell app.
When the DebugBreak() statement is hit, the following line is printed
in the terminal window:

Trace/BPT trap

I was expecting to be magically brought to the (gdb) prompt, in the
proper line of code.

What do I do next? Should I exec() gdb or something?

-Ramon

[Ramon F. Herrera]

I got it!

It seems that I MUST be running the app under the debugger.

Windows starts the debugger for you, in the proper context...

-Ramon

[ralph]

On Fri, 5 Apr 2013 09:51:36 -0700 (PDT), "Ramon F. Herrera"
<gopo...@jonjay.com> wrote:


>
>I got it!
>
>It seems that I MUST be running the app under the debugger.
>
>Windows starts the debugger for you, in the proper context...
>

What actually is going on in Windows is that you have enabled a JIT
(Just-In-Time) Debugger. With Windows you assign the debugger to use
through a Registry assignment. For example, you can setup DrWatson,
WinDbg, or the VS debugger (or any other debugger) to be automatically
run when "int 3" is reported.

Many development platforms automatically assign their debugger when
you installed the product. This is what likely happened when you
installed VS.

I'm not that familar with Linux or the gcc toolkit (I've always used
3rd party platform utilities on Unix), so I'm not sure if a 'default'
JIT Debugger is available or not, or if you have to go find a special
utility, but in any case it is something that must be
setup/configured. Researching for "JIT Debugger Linux" should get you
the information you need.

But if memory serves you can always force a coredump on the signal,
then analyze that with a debugger. That would provide a snapshot of
your application at the moment the error occured.

You set that up using the "ulimit" utility.

HTH, Just wanted to amplify on how JIT Debugging works in Windows.
I'll shut-up now and let the Linux gurus join in. <g>

-ralph

[Ramon F. Herrera]

On Apr 5, 1:15 pm, ralph <nt_consult...@yahoo.com> wrote:
> On Fri, 5 Apr 2013 09:51:36 -0700 (PDT), "Ramon F. Herrera"
>

> <gopos...@jonjay.com> wrote:
>
> >I got it!
>
> >It seems that I MUST be running the app under the debugger.
>
> >Windows starts the debugger for you, in the proper context...
>
> What actually is going on in Windows is that you have enabled a JIT
> (Just-In-Time) Debugger. With Windows you assign the debugger to use
> through a Registry assignment. For example, you can setup DrWatson,
> WinDbg, or the VS debugger (or any other debugger) to be automatically
> run when "int 3" is reported.
>
> Many development platforms automatically assign their debugger when
> you installed the product. This is what likely happened when you
> installed VS.
>

> I'm not that familar with Linux or the gcc toolkit
> (I've always used 3rd party platform utilities on Unix)

What unusual Unix do you use? I have experience with almost all of
them and with a very high degree of accuracy I can claim that U*x is
inseparable from gcc and gdb.

Even in those OSs that come with their own compiler (Solaris, AIX) you
are much better off building gcc and your applications will be
portable (across U*x, anyway).

-Ramon

[ralph]

On Fri, 5 Apr 2013 12:33:44 -0700 (PDT), "Ramon F. Herrera"
<ra...@conexus.net> wrote:

>
> > I'm not that familar with Linux or the gcc toolkit
> > (I've always used 3rd party platform utilities on Unix)
>
>What unusual Unix do you use? I have experience with almost all of
>them and with a very high degree of accuracy I can claim that U*x is
>inseparable from gcc and gdb.
>

In the face of such an adamant proclamation, as well as my own
dwindling experience with Unix over the last few years, I am forced to
admit to very poor observational skills. In 38 years of programming
I've never used gcc or gdb, nor noticed any separation anxiety from
their absence.

>Even in those OSs that come with their own compiler (Solaris, AIX) you
>are much better off building gcc and your applications will be
>portable (across U*x, anyway).
>

Hopefully my clients will remain in ignorance of that fact. They would
likely feel very foolish indeed, having spent all that extra money,
when a superior set of tools was or is available for free. <g>

-ralph

[Keith Thompson]

"Ramon F. Herrera" <ra...@conexus.net> writes:
[...]

> Even in those OSs that come with their own compiler (Solaris, AIX) you
> are much better off building gcc and your applications will be
> portable (across U*x, anyway).

That's a fairly controversial statement. In particular, I've heard
that in some cases "native" compilers other than gcc can generate
significantly more efficient code than gcc can.

(The whole point of having a language standard, after all, is that you
don't have to depend on any particular compiler.)

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Ramon F. Herrera wrote:
>
> What unusual Unix do you use? I have experience with almost all of
> them and with a very high degree of accuracy I can claim that U*x is
> inseparable from gcc and gdb.

Linux might be, but not Unix.

> Even in those OSs that come with their own compiler (Solaris, AIX) you
> are much better off building gcc and your applications will be
> portable (across U*x, anyway).

That really isn't the case.

--
Ian Collins

[Ramon F. Herrera]

You haven't answered the questions, esteemed Ralph.

- Which Unix is the one you refer to?
- Which set of tools?

We are here to share our experiences...

-Ramon

ps: There is only ONE compiler that runs across all OSs: gcc.

[Ramon F. Herrera]

On Apr 5, 5:19 pm, Keith Thompson <ks...@mib.org> wrote:
> "Ramon F. Herrera" <ra...@conexus.net> writes:
> [...]
>
> > Even in those OSs that come with their own compiler (Solaris, AIX) you
> > are much better off building gcc and your applications will be
> > portable (across U*x, anyway).
>

> That's a fairly controversial statement.  In particular, I've heard
> that in some cases "native" compilers other than gcc can generate
> significantly more efficient code than gcc can.

Not only have I heard, I have experienced it and, if you think about
it, it makes a lot of sense. This is specially true if you compare a
compiler written for some specific hardware (instruction set or
subset) against a generic one.

Last week I went to an Intel conference in Houston. Just when I
thought the i386 instruction set was as stable as possible, Intel came
up with some "extensions" for parallel processing.

Bottom line: There is a compromise between portability and efficiency
(generic vs. custom), in attire, cars, and everything else.

-Ramon