gamedevlists-linux — List for discussing game development on the linux platform

RE: [GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

> It's just a fact of life: there is not going to be a clean and portable
> way to do this.

C++, the object- oriented programming language of a pagan deity.


> On Intel linux, I wonder if you could just work back from %%ebp from a

I doubt that as the compiler is free to use EBP as it pleases - for example
as an additional general purpose register for optimizations.


> signal handler in any sort of meaningful way? Did I mention there's no
> clean, portable way to do this?  :)

Ah, I'm really looking forward to add Unicode support ;)


- Daniel Vogel, Programmer, Epic Games Inc.

RE: [GD-Linux] signals and exceptions

[Ryan C. G. <ic...@cl...>]

> Thanks for the pointer. I'll keep it in mind though at the moment I'll stick
> with our setjmp/longjmp solution for debugging as it outputs much more data
> than a normal backtrace provides. Still annoying that exceptions and signals
> don't work together - especially since this is so elegantly done on Windows.

I've been tickering with throwing from a signal handler, and have decided
that not only can it not be done, it probably shouldn't be done.

glibc's throw_helper() function (where throws end up) fires SIGABRT if you
try to throw inside a SIGSEGV handler. I presume they are trying to be
helpful, but then again, I'm not sure that signals run in the same context
(for lack of a better term) on all architectures; that is, a "backtrace"
might be nonexistant on some platforms while in the signal handler.

It's just a fact of life: there is not going to be a clean and portable
way to do this.

On Intel linux, I wonder if you could just work back from %%ebp from a
signal handler in any sort of meaningful way? Did I mention there's no
clean, portable way to do this?  :)

--ryan.

Re: [GD-Linux] signals and exceptions

[D. S. <st...@id...>]

Daniel Vogel wrote:
> 
> > A core dump will accomplish this as well, but has problems when there
> > are no debug symbols (stripped end user code), or when multiple threads
> > are in use and you need to distinguish threads. You might be interested
> > in your signal handler running ptrace within your signal handler if you
> > want customization.
> 
> Thanks for the pointer. I'll keep it in mind though at the moment I'll stick
> with our setjmp/longjmp solution for debugging as it outputs much more data
> than a normal backtrace provides. Still annoying that exceptions and signals
> don't work together - especially since this is so elegantly done on Windows.

They could be made to work together, but then you'd really have to worry
about whether you did it right, and the system of making various parts
"atomic" would lead to a lot of overhead you already don't want. The
thing is that the underlying libc of linux and all UNIX is old C-based,
and did not have the concept of exceptions built in to it. It makes the
system itself rather stable and low overhead (had linux been C++ based,
bootup support would be massive in comparison with what it is now), but
isn't very friendly to exceptions.

D. Stimits, st...@id...

> 
> - Daniel Vogel, Programmer, Epic Games Inc.
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux

RE: [GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

> A core dump will accomplish this as well, but has problems when there
> are no debug symbols (stripped end user code), or when multiple threads
> are in use and you need to distinguish threads. You might be interested
> in your signal handler running ptrace within your signal handler if you
> want customization.

Thanks for the pointer. I'll keep it in mind though at the moment I'll stick
with our setjmp/longjmp solution for debugging as it outputs much more data
than a normal backtrace provides. Still annoying that exceptions and signals
don't work together - especially since this is so elegantly done on Windows.

- Daniel Vogel, Programmer, Epic Games Inc.

Re: [GD-Linux] signals and exceptions

[D. S. <st...@id...>]

Daniel Vogel wrote:
> 
> > The underlying memory violation is part of the glibc libraries, and does
> > not originate from the application itself, so a general means of
> > converting to an exception won't happen. How you deal with it might
> > depend on whether you are using threads or not. In the case of threads,
> > you'd mask all but one thread to not catch signals; likely the main
> > thread would do signal handling. Regardless, you do not want to mix
> > signal handling with exceptions without being very careful. So one
> > question is whether you are using threads, and a second question is what
> > you want to do when this signal is sent...can you live with abandoning
> > the current thread or function? I see you're trying to catch and work
> > with the exception within the sample function (which is just main() in
> > this case), but in actual use, will that be needed? You could create a
> > global or per-thread state object, have your signal handler set this,
> > and instead of try/catch, just have your blocks:
> >   {  // NOTE: no "try".
> >      ...general stuff that might have SIGSEGV...
> >      // if something goes wrong, signal handler sets oSigState.
> >   }
> >   oSigState.mRethrow();
> >
> > (where rethrow() does nothing if a mapping does not exist between a
> > particular signal and a substitute exception; you could take it further
> > and allow specification of signals, e.g., oSigState.mRethrow(SIGSEGV),
> > which would ignore any signal state other than SIGSEGV)
> >
> > It depends a lot on what you want to accomplish and whether you are
> > using threads.
> 
> We just use exceptions to print out a meaningful stack backtrace when the
> game crashes and it relies on unwinding the stack as every function has it's
> name in ASCII on the stack.

A core dump will accomplish this as well, but has problems when there
are no debug symbols (stripped end user code), or when multiple threads
are in use and you need to distinguish threads. You might be interested
in your signal handler running ptrace within your signal handler if you
want customization.

D. Stimits, st...@id...

> 
> Thanks for all your suggestions (D.Stimits, Mark Collins) - I'll look into
> this a bit further and let you know how it goes. I finally want to get rid
> of all the ugly code in the Linux code and this and Unicode support are the
> two things on my plate.
> 
> > My "reply-to" button just lists your address, not the list. Plus, I'm
> > subscribed to the gd algo and opengl lists, and this is arriving and
> > being sent to my general sourceforge box, since I don't have a rule for
> > general "gamedevlists-linux" (I should, I love linux game dev, it's
> > about all I do).
> 
> I'll simply keep sending my replies to the list.
> 
> > D. Stimits, st...@id...
> 
> - Daniel Vogel, Programmer, Epic Games Inc.
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux

RE: [GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

> The underlying memory violation is part of the glibc libraries, and does
> not originate from the application itself, so a general means of
> converting to an exception won't happen. How you deal with it might
> depend on whether you are using threads or not. In the case of threads,
> you'd mask all but one thread to not catch signals; likely the main
> thread would do signal handling. Regardless, you do not want to mix
> signal handling with exceptions without being very careful. So one
> question is whether you are using threads, and a second question is what
> you want to do when this signal is sent...can you live with abandoning
> the current thread or function? I see you're trying to catch and work
> with the exception within the sample function (which is just main() in
> this case), but in actual use, will that be needed? You could create a
> global or per-thread state object, have your signal handler set this,
> and instead of try/catch, just have your blocks:
>   {  // NOTE: no "try".
>      ...general stuff that might have SIGSEGV...
>      // if something goes wrong, signal handler sets oSigState.
>   }
>   oSigState.mRethrow();
>
> (where rethrow() does nothing if a mapping does not exist between a
> particular signal and a substitute exception; you could take it further
> and allow specification of signals, e.g., oSigState.mRethrow(SIGSEGV),
> which would ignore any signal state other than SIGSEGV)
>
> It depends a lot on what you want to accomplish and whether you are
> using threads.

We just use exceptions to print out a meaningful stack backtrace when the
game crashes and it relies on unwinding the stack as every function has it's
name in ASCII on the stack.

Thanks for all your suggestions (D.Stimits, Mark Collins) - I'll look into
this a bit further and let you know how it goes. I finally want to get rid
of all the ugly code in the Linux code and this and Unicode support are the
two things on my plate.


> My "reply-to" button just lists your address, not the list. Plus, I'm
> subscribed to the gd algo and opengl lists, and this is arriving and
> being sent to my general sourceforge box, since I don't have a rule for
> general "gamedevlists-linux" (I should, I love linux game dev, it's
> about all I do).

I'll simply keep sending my replies to the list.


> D. Stimits, st...@id...


- Daniel Vogel, Programmer, Epic Games Inc.

RE: [GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

> The problem is not the printf. The problem is that memory violations do
> not generate exceptions, they generate a signal. Check man -a signal;
> trap SIGSEGV.

Yes, I'm painfully aware of that fact and am wondering whether there were a
way to make that work cleanly. I thought about throwing an exception in a
signal handler but doubt that'll work fine and I guess it's going to create
weird side effects. At the moment we use setjmp/longjmp from within signal
handlers to emulate exceptions and it's a considerable performance impact (I
took it out for the UT Linux versions I worked on) whereof the exception
equivalent is virtually free on Windows.

BTW, I get a lot of email sent to me privately and I simply assume it's
meant to be for the list in my replies so add a <private reply> or whatever
somewhere to your replies if you don't want me to reply to your message to
the list :)

- Daniel Vogel, Programmer, Epic Games Inc.

[GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

Does anyone know what I have to do get the printf in the below code example
to be executed on Linux? Our current approach to achieve that uses signal
handlers, macros and setjmp which is ugly, slow and an overall PITA.


#include <stdio.h>

int main()
{
        try
        {
                int* pointer  = NULL;
                int crash     = *pointer;
        }
        catch( ... )
        {
                printf("I want to be executed\n");
        }
        return 0;
}


- Daniel Vogel, Programmer, Epic Games Inc.

RE: [GD-Linux] Intel's C++ compiler

[Daniel V. <vo...@ep...>]

icc is well documented but for those who don't want to browse the 361 page
pdf here is a small summary of differences

gcc:

1. -export-dynamic
2. -fPIC -shared -Wl,-soname,$SONAME
3. #if __GNUG__

icc:

1. -Qoption,link,--export-dynamic
2. -KPIC -shared -Qoption,link,-soname,$SONAME
3. #if __ICC

BTW, icc supports #pragma pack and -Zp[n] which should make porting from
Windows easier :)

- Daniel Vogel, Programmer, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Daniel Vogel
> Sent: Tuesday, November 13, 2001 2:34 AM
> To: gam...@li...
> Subject: RE: [GD-Linux] Intel's C++ compiler
>
>
> Nope, I'm wrong. It seems to use ld for linking.
>
> - Daniel Vogel, Programmer, Epic Games Inc.
>
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]On Behalf Of
> > Daniel Vogel
> > Sent: Monday, November 12, 2001 11:04 PM
> > To: gam...@li...
> > Subject: RE: [GD-Linux] Intel's C++ compiler
> >
> >
> > > Does it have its own linker?  If not what are the link times like?
> >
> > Yes (or I at least think it does have it's own linker). It feels a bit
> > faster than with gcc but linking time never was an issue with the Unreal
> > engine as opposed to *cough*SC3K*cough* ;-)
> >
> > - Daniel Vogel, Programmer, Epic Games Inc.
> >
> >
> > _______________________________________________
> > Gamedevlists-linux mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
> >
>
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
>

RE: [GD-Linux] Intel's C++ compiler

[Daniel V. <vo...@ep...>]

Nope, I'm wrong. It seems to use ld for linking.

- Daniel Vogel, Programmer, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Daniel Vogel
> Sent: Monday, November 12, 2001 11:04 PM
> To: gam...@li...
> Subject: RE: [GD-Linux] Intel's C++ compiler
> 
> 
> > Does it have its own linker?  If not what are the link times like?
> 
> Yes (or I at least think it does have it's own linker). It feels a bit
> faster than with gcc but linking time never was an issue with the Unreal
> engine as opposed to *cough*SC3K*cough* ;-)
> 
> - Daniel Vogel, Programmer, Epic Games Inc.
> 
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
> 

RE: [GD-Linux] Intel's C++ compiler

[Daniel V. <vo...@ep...>]

> Does it have its own linker?  If not what are the link times like?

Yes (or I at least think it does have it's own linker). It feels a bit
faster than with gcc but linking time never was an issue with the Unreal
engine as opposed to *cough*SC3K*cough* ;-)

- Daniel Vogel, Programmer, Epic Games Inc.

Re: [GD-Linux] Intel's C++ compiler

[Joe V. <jva...@li...>]

On Mon, Nov 12, 2001 at 02:32:15AM -0500, Daniel Vogel wrote:
> I installed the evaluation today and I'm really impressed. The compile speed
> is amazing and I haven't even played with precompiled headers yet! It only
> took me about half an hour to convert from gcc to icc but we have a nice
> abstraction layer and don't use non ANSI C++ code or weird template stuff so
> YMMV.

Does it have its own linker?  If not what are the link times like?

-- 
J. Valenzuela  --  jva...@li...
Only those who leisurely approach that which the masses are busy about
can be busy about that which the masses take leisurely.
		-- Lao Tsu

RE: [GD-Linux] Intel's C++ compiler

[Daniel V. <vo...@ep...>]

I installed the evaluation today and I'm really impressed. The compile speed
is amazing and I haven't even played with precompiled headers yet! It only
took me about half an hour to convert from gcc to icc but we have a nice
abstraction layer and don't use non ANSI C++ code or weird template stuff so
YMMV.

- Daniel Vogel, Programmer, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Daniel Vogel
> Sent: Tuesday, November 06, 2001 6:06 PM
> To: gam...@li...
> Subject: [GD-Linux] Intel's C++ compiler
>
>
> Has anyone tried Intel's C++ compiler for Linux? I have some template code
> here that refuses to compile with any version of gcc >= 2.96 and am
> wondering what people's experience are with the Intel compiler with regard
> to C++ conformance (according to the German iX magazine it's
> supposed to be
> good)?
>
> - Daniel Vogel, Programmer, Epic Games Inc.
>
>
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
>

Re: [GD-Linux] Intel's C++ compiler

[Ryan C. G. <ic...@cl...>]

> AWGTHTGTTA? http://www.unicom.com/pw/reply-to-harmful.html

I am dying to know what "AWGTHTGTTA" means.

--ryan.

RE: [GD-Linux] Intel's C++ compiler

[Hal A. <ha...@cl...>]

I have agreed to the 30-day demo. I've even downloaded it....I just haven't
actually compiled anything with it yet.

Sorry, just adding to the noise to signal ratio :)

Hal.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of Bert
Freudenberg
Sent: 07 November 2001 08:02
To: gam...@li...
Subject: Re: [GD-Linux] Intel's C++ compiler


On Wed, 7 Nov 2001, Timothee Besset wrote:

> I've been willing to, but haven't looked at Intel's C++ compiler for Linux
> yet .. but I hear they have a 30 days demo available. Anyone else?

Yep, see http://developer.intel.com/software/products/compilers/c50/linux/

The German c't magazin had a review this week. They were quite pleased,
although it doesn't compile the kernel, yet.

> Not sure how many are subscribed to the list actually, this is a good time
> for a ping..

Pong :)

> PS: SourceForge's new email policy of setting reply to to the poster
> blows.

AWGTHTGTTA? http://www.unicom.com/pw/reply-to-harmful.html

-- Bert



_______________________________________________
Gamedevlists-linux mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux

Re: [GD-Linux] Intel's C++ compiler

[Bert F. <be...@is...>]

On Wed, 7 Nov 2001, Timothee Besset wrote:

> I've been willing to, but haven't looked at Intel's C++ compiler for Linux
> yet .. but I hear they have a 30 days demo available. Anyone else?

Yep, see http://developer.intel.com/software/products/compilers/c50/linux/

The German c't magazin had a review this week. They were quite pleased, 
although it doesn't compile the kernel, yet.

> Not sure how many are subscribed to the list actually, this is a good time
> for a ping..

Pong :)

> PS: SourceForge's new email policy of setting reply to to the poster
> blows.

AWGTHTGTTA? http://www.unicom.com/pw/reply-to-harmful.html

-- Bert

RE: [GD-Linux] Intel's C++ compiler

[Daniel V. <vo...@ep...>]

> I think you have the first post here Daniel :-)

:)


> I've been willing to, but haven't looked at Intel's C++ compiler for Linux
> yet .. but I hear they have a 30 days demo available. Anyone else?

I'm concerned about the time involved to get it up and running just to
realize that there are either the same or different issues.


> Is your template code related to STL, or fully custom? Do you know what

Custom - nothing fancy just some very basic template usage. In one case I
had to explicitely instantiate a template to make it compile and in another
case no mojo worked to get it to compile with gcc >= 2.96. Also gcc >= 3.0
now warns about multi-line literals being deprecated and I couldn't find a
way to turn off that warning - the code in question isn't even compiled
(#ifdef'ed out for another platform) and apparently the warning in this case
is by design... sigh.

2.95.3 (couldn't use 2.95.2 due to glibc incompatibilities) compiled the
code fine except one occurance I solved by using explicit instantiation.


> exactly are the template features missing in gcc? I believe the official
> stable version of gcc is still a 2.95.X anyway?

Yes but 2.95.x doesn't support 2 byte Unicode :)


> PS: SourceForge's new email policy of setting reply to to the poster
> blows.

Yup.


- Daniel Vogel, Programmer, Epic Games Inc.

Re: [GD-Linux] Intel's C++ compiler

[Timothee B. <tt...@id...>]

I think you have the first post here Daniel :-)

I've been willing to, but haven't looked at Intel's C++ compiler for Linux
yet .. but I hear they have a 30 days demo available. Anyone else?

Is your template code related to STL, or fully custom? Do you know what
exactly are the template features missing in gcc? I believe the official
stable version of gcc is still a 2.95.X anyway?

TTimo

Not sure how many are subscribed to the list actually, this is a good time
for a ping..

PS: SourceForge's new email policy of setting reply to to the poster
blows.

On Tue, 6 Nov 2001 18:05:47 -0500
"Daniel Vogel" <vo...@ep...> wrote:

> Has anyone tried Intel's C++ compiler for Linux? I have some template code
> here that refuses to compile with any version of gcc >= 2.96 and am
> wondering what people's experience are with the Intel compiler with regard
> to C++ conformance (according to the German iX magazine it's supposed to be
> good)?
> 
> - Daniel Vogel, Programmer, Epic Games Inc.
> 
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux

[GD-Linux] Intel's C++ compiler

[Daniel V. <vo...@ep...>]

Has anyone tried Intel's C++ compiler for Linux? I have some template code
here that refuses to compile with any version of gcc >= 2.96 and am
wondering what people's experience are with the Intel compiler with regard
to C++ conformance (according to the German iX magazine it's supposed to be
good)?

- Daniel Vogel, Programmer, Epic Games Inc.