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

Re: [GD-Linux] Determining address of C++ member function at run-time...

[Colin F. <cp...@ea...>]

December 12th, 2001
Wednesday

The primary reason I asked about finding the address
of the implementation of non-static C++ class member
functions was to satisfy my curiousity; I like to
know how things work. But there was another reason...

I built my own shared-library file (*.so), which had
a few C and C++ static libraries (*.a) collected in
there, in addition to my C++ object code (*.o).

If you do "nm foo.so" and "objdump foo.so" you
can learn a lot about the structure of the shared
library file.  In particular, you can see all of the
function addresses (including non-static member 
functions).

Okay, I also have an executable that loads my
shared library at run-time.  I have no source code
for the executable, and it was stripped of symbols.

When the executable invokes a method in my
shared library, some part of the shared library
causes a crash.

There is code that successfully "unwinds" the call
stack, so I get the addresses of all functions
at the time of the crash.

One of my co-workers wrote a Perl (ugh!) script
that parses the stack trace and uses the output
of "nm" and "objdump" to produce a friendly
trace -- listing functions and line numbers!

However, this script only works on regular
executables with everything linked in.

When a shared library is loaded, all of the
code is re-located.  In order to use the Perl
script mentioned above, I had to determine
where the code was placed in virtual memory.
I picked an arbitrary function, printed its
address at run-time, and compared this to the
address indicated by "nm" or "objdump".
I subtracted the difference in the Perl script,
and now I get a valid stack trace for my
shared library crash! ***NOTE: The function
I chose was a straight C (extern "C" to avoid
mangled names) function, whose address is
trivial to print. ***

Just to reassure myself that the addresses
for the ***C++ non-static member functions*** were
sane (in addition to the static member functions
and straight C functions, whose addresses are
trivial to print), I wanted to be able to print
them -- thus the question I posted to this list.

What I ended up doing was this:

  extern void MyFunction__8MyClassi();

  printf( "%p", MyFunction__8MyClassi );

This prints the run-time address of the
implementation of the non-static member
function MyClass::MyFunction -- and my
"extern" function prototype is completely
artificial; it's just enough to keep the
compiler from complaining about the symbol
'MyFunction__8MyClassi' being unknown...
(...yet, heh, heh!)  My fake prototype has
to be a function (or something similar),
but I don't need to match the arguments 
and return value of the actual function
(with the specified mangled name).

As I clearly mentioned in my initial post,
I was willing to do any hack or frown-upon
technique just to get the answer.

This trick worked perfectly;  I found that
all of the code (C++ static and non-static
functions alike) was relocated by the same
constant offset at run-time.

I'm still stuck with this crash, though.
The problem is, part of the stack trace
includes addresses that I can't explain.
I can account for all of the code that is
*DIRECTLY* contained in the shared library.
But if the shared library itself loads
even more shared libraries at run-time,
and the crash is happening inside one
of them...Uh, ohhh!

Well, I won't bore you with more details
of my problem (which is even more convoluted
than I can explain here), but maybe I'll 
ask one last question:

  Can you use gdb to debug an executable-
  without-debugging-information just for
  the sake of debugging a shared library
  (whose symbols you *DO* have)?

It's a crazy, multi-threaded, Java/C++
hybrid, with lots of library loading on
both sides...  Believe me, I completely
agree that wanting to know the addresses
of C++ member functions should never be
necessary for any application!  But I
wanted to do some sanity checking before
entertaining some wacky theories about
the crashing.  I'm not a Linux guru, and
I haven't mastered debugging on that platform.

Thanks, Ryan, for the interesting gcc compiler
trick:

printf("address of my_label is (%p).\n", &&my_label);

I just like knowing that this can be done, even
if I have no immediate plans to do this.

--- Colin P. Fahey
cp...@ea...

Re: [GD-Linux] Determining address of C++ member function at run-time...

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

> Is dlopen/dlsym applicable here?

The problem with dlsym() is that the symbol would be mangled in a way that
varies between versions of gcc, so it's best for the dynamic linker to do
this work.

The odd thing is that, when statically linked, the code that Colin posted
( printf("%p", &(Foo::Bar)); ) works fine here.

You could always do something like this (which is uglier, but probably
safer, dlsym or otherwise):

extern "C"
{
   void FooBarEntry(void)
   {
       Foo::Bar();
   }
}

then do your lookup on FoorBarEntry instead of Foo::Bar. I dunno. I tend
to agree with Steve, there's probably a better way to do this without
resorting to this sort of thing.

> What I don't understand is *WHY* you need to do this.  It seems
> like you must be doing something unbelievably **NASTY** and you ought
> to be looking for a better way to solve the problem than delving around
> in ikky machine details such as code addresses.

I'm rapidly coming to the belief that this should be the standard reply to
any questions on this list.  :)

--ryan.

Re: [GD-Linux] Determining address of C++ member function at run-time...

[Steve B. <sjb...@ai...>]

Colin Fahey wrote:

> I have a Linux shared-library (*.so) file with lots
> of C++ classes.  I would like to determine the addresses
> of the binary code implementations of various
> NON-STATIC member functions at run-time (not at
> compile-time or doing "nm foo.so" at the command line).

Is dlopen/dlsym applicable here?
 
What I don't understand is *WHY* you need to do this.  It seems
like you must be doing something unbelievably **NASTY** and you ought
to be looking for a better way to solve the problem than delving around
in ikky machine details such as code addresses.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [GD-Linux] Determining address of C++ member function atrun-time...

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

"Ryan C. Gordon" wrote:
> 
> > That leads me to another question:  How can
> > I get the run-time address of C++ statements?
> > For example, suppose I do this:
> >
> >      goto  my_label;
> >
> >      my_label:
> >        printf("Happy day, citizen!\n");
> >
> > Could I figure out the approximate address of
> > the "printf" call (NOT the location of the
> > implementation of printf(), but the local
> > "line" of code where the "call printf"
> > assembly language is) just by doing the
> > following:
> >
> >     printf( "%x", (unsigned int)(my_label) );
> >
> > or something similar?
> 
> Not portably. There IS a gcc extension, though:
> 
>   printf("address of my_label is (%p).\n", &&my_label);

If you don't mind compiling it in, there are standard defines under gcc
(I think on most platforms, not just linux) of __FILE__ and __LINE__.
E.G.:
printf( "%s at line %s\n", __FILE__, __LINE__ );

Assuming you can live with file name and line number, it'll do the
trick.

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

> 
> That is TWO ampersands, and is NOT a typo.
> 
> And did I mention it's not portable. Chances are, if you need this, you
> also need to rethink your design.
> 
> > Am I allowed to read any code pages just like
> > memory allocated on the heap?  I mean *MY* code
> > pages.  So is it possible to scan through the
> > assembly language opcodes of my own program
> > to search for code?
> 
> By default, you have read and execute access to memory pages that
> represent your program. You need to change that to have write access, too,
> if you plan to do any self-modifying code, or you'll segfault.
> 
> --ryan.
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux

Re: [GD-Linux] Determining address of C++ member function at run-time...

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

> That leads me to another question:  How can
> I get the run-time address of C++ statements?
> For example, suppose I do this:
>
>      goto  my_label;
>
>      my_label:
>        printf("Happy day, citizen!\n");
>
> Could I figure out the approximate address of
> the "printf" call (NOT the location of the
> implementation of printf(), but the local
> "line" of code where the "call printf"
> assembly language is) just by doing the
> following:
>
>     printf( "%x", (unsigned int)(my_label) );
>
> or something similar?

Not portably. There IS a gcc extension, though:

  printf("address of my_label is (%p).\n", &&my_label);

That is TWO ampersands, and is NOT a typo.

And did I mention it's not portable. Chances are, if you need this, you
also need to rethink your design.

> Am I allowed to read any code pages just like
> memory allocated on the heap?  I mean *MY* code
> pages.  So is it possible to scan through the
> assembly language opcodes of my own program
> to search for code?

By default, you have read and execute access to memory pages that
represent your program. You need to change that to have write access, too,
if you plan to do any self-modifying code, or you'll segfault.

--ryan.

[GD-Linux] Determining address of C++ member function at run-time...

[Colin F. <cp...@ea...>]

December 11, 4004 B.C.
Tuesday

I have a Linux shared-library (*.so) file with lots
of C++ classes.  I would like to determine the addresses
of the binary code implementations of various 
NON-STATIC member functions at run-time (not at
compile-time or doing "nm foo.so" at the command line).

For example, let's say I have:

class Foo
{
public:
  int Bar( int, char *, float );
};

I'd like to do something like:

printf( "%p", &(Foo::Bar) );

The problem is, this print statement gives me
a wacky answer (like 0xffff0000, for example).

I know that pointer-to-member-function is
more than a simple C pointer -- since it must
have information regarding virtual function
tables, etc.  I also know that there is an
implicit "this" parameter to all non-static
member functions:

int Foo::Bar( [Foo *this,] int, char *, float );
               IMPLICIT

Perhaps this is not always the case, especially
if the member function only accesses static
member functions and variables -- in which case
the "this" parameter is superfluous.

Anyhow, I want a 32-bit address of the 
assembly language implementation of Foo::Bar()
without instantiating a Foo class object,
and without calling Foo::Bar().

*** I don't mind any assembly language "hack",
or any non-portable, frown-upon trickery. ***

Ideally the technique would be "self-contained";
i.e., something I could do with a few lines of
code or assembly code, without changing any
external source files.  For example, I *don't*
want to modify the source code of the C++
classes themselves!  Oh, and the technique must
do calculations at run-time, and must work
even for re-located shared-library code.

One idea I had for this problem is this:
write code to call the method, but never
execute it, and then search backwards for
the "call" instruction, and get the address.

That leads me to another question:  How can
I get the run-time address of C++ statements?
For example, suppose I do this:
     
     goto  my_label;
    
     my_label:
       printf("Happy day, citizen!\n");

Could I figure out the approximate address of
the "printf" call (NOT the location of the 
implementation of printf(), but the local
"line" of code where the "call printf"
assembly language is) just by doing the
following:

    printf( "%x", (unsigned int)(my_label) );

or something similar?

Am I allowed to read any code pages just like
memory allocated on the heap?  I mean *MY* code
pages.  So is it possible to scan through the
assembly language opcodes of my own program
to search for code?

Okay, that's a lot of material -- and probably
too hard-core for this list -- but I think a
few of you guys have the expertise to help me
with this puzzle.  I did lots of Google searching,
but everyone is happy making statements like
"just declare a pointer-to-member-function to
implement callbacks...C++ is great...who cares
about the secret mechanics!"

--- Colin P. Fahey

Re: [GD-Linux] ANSI/ISO C++

[Gareth H. <gar...@ac...>]

GCC 3.0.2 is perhaps the best (released) version of GCC I've used.  The
C++ compiler is meant to be ISO C++ compliant, but as I don't really do
any C++ programming I can't verify this.  I would recommend checking
this out initially.  For example, the x86 backend was rewritten for 3.0,
and generally produces much better code -- my personal favourite is
moving floating point data through the integer registers when
appropriate (integer regs: 2 cycle latency, fp regs: 7 cycle latency on
a P4, for instance).

-- Gareth

Re: [GD-Linux] ANSI/ISO C++

[J C L. <cl...@ka...>]

On Tue, 11 Dec 2001 14:29:44 -0000 
Vincent Penquerc'h <Vin...@ar...> wrote:

> There are several issues: - GCC runs on an astounding number of
> platforms, and thus needs to optimize for all of them, so
> compromises have to be done.  

The fact that GCC throws away much of the data at the beginning of
the compilation pipeline that could be later used for more
interesting optimisations really doesn't help.  FWVLIW this was the
major driving force behind SGI Open Sourcing their compiler for the
Linux/AI64 project.

> Sorry for the HTML, MS Exchange bug, blah, blah, sysop not done
> the upgrade yet, blah.

Ahh, the wonders of a mail client configured to displau text/plain
in preference to text/html!  I just don't hve to notice that sort of
silliness anymore.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-Linux] ANSI/ISO C++

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

Matt Davies wrote:
> 
> I would like to use the techniques used in Modern C++ Design and the Loki
> library.  This is however impossible as MSVC (my only current compiler) does
> not support partial template specialisation or template template parameters
> (when are they going to get their act together on this).
> 
> I hoped that perhaps GCC (on Linux) would support templates properly and I
> will try out version 3.0 - thanks.  As for Windows I've tried out Borland
> C++ 5.5 which handles them nicely except I cannot use its debugger with any
> executable that I create.  Could someone let me known how this is done.

g++ 2.96 of redhat supports partial specialization. The 3.x series does.
I don't know if the older 2.91.x supports it or not. Even if older ones
support partial specialization, I'd recommend going newer g++ due to
much better STL support (this is probably due more to packaging than to
the compiler itself, but I'm not sure). IMHO, the template support on
2.96+ is really nice for g++, the only real complaint I know of there is
that lots of templates results in long compile times. I don't know what
LOKI uses, I suggest you just give it a try. As someone else mentioned,
there is no such thing as a fully ANSI/ISO C++ compiler. If you are
going to distribute source code, you probably want what you expect the
end user to compile on; if sending binary code, probably whatever gives
you the best code and most coding quality.

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

> 
> I plan to implement my code on Linux when I install it.  I do have the Code
> Fusion compiler which I bought 2 years ago which is GCC with help from
> Intel.  I am hoping that it has decent template support.  But I doubt it.
> Is the free GCC not that efficient at optimising then?
> 
> I would like to take this conversation to SWENG but it seems to be down and
> I haven't heard a peep from it for a few days now.  I am hoping that a few
> on this list subscribe to SWENG so please forgive me when I ask this
> question:
> 
> Has anyone converted the LOKI library to not use partial template
> specialisation so that I can compile it under MSVC?
> 
> Cheers,
> 
> Matt Davies
> Programmer, Confounding Factor
> ma...@co...
> www.confounding-factor.com
> 
> -----Original Message-----
> From: Daniel Vogel [mailto:vo...@ep...]
> Sent: 11 December 2001 10:03
> To: Matt Davies; gam...@li...
> Subject: RE: [GD-Linux] ANSI/ISO C++
> 
> None of the commercial compilers out there supports the full range of the
> ISO C++ Standard though on either the sweng or algorithm list someone posted
> a list of "research" compilers that claim to be fully compliant.
> 
> gcc 3.0 seems to have okay template support though I can't really tell as we
> hit a regression with gcc >= 2.96. You might try Intel's C++ compiler - it's
> not free for commercial use but I think you can use it for free if you are
> student or something like that. For a personal project it might be worth
> looking up the details as the compiler is $400 otherwise IIRC. If it's for
> real (time==money) use it's worth every penny as it compiles code roughly
> three times faster than gcc :)
> 
> On Windows MSVC is free IIRC as long as you are a student or for non
> commercial use (as above I only vaguely remember the terms) though they only
> provide you with access to a non optimizing version of the compiler. MSVC
> has a nice IDE and debugger so you might want to give that a try.
> 
> BTW, cross platformness and nifty template tricks are usually mutually
> exclusive - at least in my experience. Michael Vance @ TreyArch should be
> able to tell a lot of horror stories ;)
> 
> -- Daniel, Epic Games Inc.
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of Matt
> Davies
> Sent: Tuesday, December 11, 2001 4:36 AM
> To: gam...@li...
> Subject: [GD-Linux] ANSI/ISO C++
> 
> Hi,
> 
> Is there any free compilers for Linux that supports the full ANSI/ISO C++
> language - which includes template template parameters and partial template
> specialisation.  Does GCC support them yet?  I need a compiler for Windows
> as well.  Borland C++ 5.5 seems to do the job but I've had no luck making it
> work with the Turbo Debugger.  Perhaps someone can provide me with help
> there?
> 
> BTW, does anyone know whats happened to the SWENG mailing list.  I've sent
> some messages out but I haven't received any.  Is it down?
> 
> Best regards,
> 
> Matt Davies
> Programmer, Confounding Factor
> ma...@co...
> www.confounding-factor.com
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux

Re: [GD-Linux] ANSI/ISO C++

[Mark C. <me...@th...>]

On Tuesday 11 December 2001  9:35 am, Matt Davies wrote:
<snip>

On a vaguely unrelated matter, the Linux beta of VectorC is going to be 
starting in a couple of months, and I've been given the task of finding 
people who want to beta test it.

Let me know (off-list) if you're interested.

-- 
===
Mark 'Nurgle' Collins
Lead Author - Linux Game Programming (Premiere Press)
Author - Advanced AI Game Development (WordWare)
Email: me...@th...	Phone: +44 7761 774 152
Email: nu...@is...	Spam: sp...@th...

RE: [GD-Linux] ANSI/ISO C++

[Vincent Penquerc'h <Vin...@ar...>]

> Is the free GCC not that efficient at optimising then?

There are several issues:
- GCC runs on an astounding number of platforms, and thus needs
  to optimize for all of them, so compromises have to be done.
- On the same subject, divide the amount of effort spent by the
  number of supported platforms and you get the amount of effort
  that goes into a particular platform (well, not strictly, since
  IA32 gets a fair share, but you get the idea).
- Some optimizations require knowledge of the architecture that
  sometimes can be gotten only through an NDA, and GCC being
  free software can't always do that (since the code exploiting
  these features would be available and might violate an NDA)
- Many contributors to FSF GCC are volunteers, so the deadlines
  are not the same as they would be at MS (even tech ones).

Sorry for the HTML, MS Exchange bug, blah, blah, sysop not done
the upgrade yet, blah.

-- 
Vincent Penquerc'h 

RE: [GD-Linux] ANSI/ISO C++

[Matt D. <ma...@co...>]

I would like to use the techniques used in Modern C++ Design and the Loki
library.  This is however impossible as MSVC (my only current compiler) does
not support partial template specialisation or template template parameters
(when are they going to get their act together on this).

I hoped that perhaps GCC (on Linux) would support templates properly and I
will try out version 3.0 - thanks.  As for Windows I've tried out Borland
C++ 5.5 which handles them nicely except I cannot use its debugger with any
executable that I create.  Could someone let me known how this is done.

I plan to implement my code on Linux when I install it.  I do have the Code
Fusion compiler which I bought 2 years ago which is GCC with help from
Intel.  I am hoping that it has decent template support.  But I doubt it.
Is the free GCC not that efficient at optimising then?

I would like to take this conversation to SWENG but it seems to be down and
I haven't heard a peep from it for a few days now.  I am hoping that a few
on this list subscribe to SWENG so please forgive me when I ask this
question:

Has anyone converted the LOKI library to not use partial template
specialisation so that I can compile it under MSVC?

Cheers,


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com



-----Original Message-----
From: Daniel Vogel [mailto:vo...@ep...]
Sent: 11 December 2001 10:03
To: Matt Davies; gam...@li...
Subject: RE: [GD-Linux] ANSI/ISO C++


None of the commercial compilers out there supports the full range of the
ISO C++ Standard though on either the sweng or algorithm list someone posted
a list of "research" compilers that claim to be fully compliant.

gcc 3.0 seems to have okay template support though I can't really tell as we
hit a regression with gcc >= 2.96. You might try Intel's C++ compiler - it's
not free for commercial use but I think you can use it for free if you are
student or something like that. For a personal project it might be worth
looking up the details as the compiler is $400 otherwise IIRC. If it's for
real (time==money) use it's worth every penny as it compiles code roughly
three times faster than gcc :)

On Windows MSVC is free IIRC as long as you are a student or for non
commercial use (as above I only vaguely remember the terms) though they only
provide you with access to a non optimizing version of the compiler. MSVC
has a nice IDE and debugger so you might want to give that a try.

BTW, cross platformness and nifty template tricks are usually mutually
exclusive - at least in my experience. Michael Vance @ TreyArch should be
able to tell a lot of horror stories ;)

-- Daniel, Epic Games Inc.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of Matt
Davies
Sent: Tuesday, December 11, 2001 4:36 AM
To: gam...@li...
Subject: [GD-Linux] ANSI/ISO C++


Hi,

Is there any free compilers for Linux that supports the full ANSI/ISO C++
language - which includes template template parameters and partial template
specialisation.  Does GCC support them yet?  I need a compiler for Windows
as well.  Borland C++ 5.5 seems to do the job but I've had no luck making it
work with the Turbo Debugger.  Perhaps someone can provide me with help
there?

BTW, does anyone know whats happened to the SWENG mailing list.  I've sent
some messages out but I haven't received any.  Is it down?

Best regards,


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com

Re: [GD-Linux] ANSI/ISO C++

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

Yup .. never go too far into C++ stuff if you want to be cross-platform ..
from my experience STL is already the limit :-)

TTimo

On Tue, 11 Dec 2001 05:02:49 -0500
"Daniel Vogel" <vo...@ep...> wrote:

> None of the commercial compilers out there supports the full range of the
> ISO C++ Standard though on either the sweng or algorithm list someone posted
> a list of "research" compilers that claim to be fully compliant.
> 
> gcc 3.0 seems to have okay template support though I can't really tell as we
> hit a regression with gcc >= 2.96. You might try Intel's C++ compiler - it's
> not free for commercial use but I think you can use it for free if you are
> student or something like that. For a personal project it might be worth
> looking up the details as the compiler is $400 otherwise IIRC. If it's for
> real (time==money) use it's worth every penny as it compiles code roughly
> three times faster than gcc :)
> 
> On Windows MSVC is free IIRC as long as you are a student or for non
> commercial use (as above I only vaguely remember the terms) though they only
> provide you with access to a non optimizing version of the compiler. MSVC
> has a nice IDE and debugger so you might want to give that a try.
> 
> BTW, cross platformness and nifty template tricks are usually mutually
> exclusive - at least in my experience. Michael Vance @ TreyArch should be
> able to tell a lot of horror stories ;)
> 
> -- Daniel, Epic Games Inc.
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of Matt
> Davies
> Sent: Tuesday, December 11, 2001 4:36 AM
> To: gam...@li...
> Subject: [GD-Linux] ANSI/ISO C++
> 
> 
> Hi,
> 
> Is there any free compilers for Linux that supports the full ANSI/ISO C++
> language - which includes template template parameters and partial template
> specialisation.  Does GCC support them yet?  I need a compiler for Windows
> as well.  Borland C++ 5.5 seems to do the job but I've had no luck making it
> work with the Turbo Debugger.  Perhaps someone can provide me with help
> there?
> 
> BTW, does anyone know whats happened to the SWENG mailing list.  I've sent
> some messages out but I haven't received any.  Is it down?
> 
> Best regards,
> 
> 
> Matt Davies
> Programmer, Confounding Factor
> ma...@co...
> www.confounding-factor.com
> 
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
> 

RE: [GD-Linux] ANSI/ISO C++

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

None of the commercial compilers out there supports the full range of the
ISO C++ Standard though on either the sweng or algorithm list someone posted
a list of "research" compilers that claim to be fully compliant.

gcc 3.0 seems to have okay template support though I can't really tell as we
hit a regression with gcc >= 2.96. You might try Intel's C++ compiler - it's
not free for commercial use but I think you can use it for free if you are
student or something like that. For a personal project it might be worth
looking up the details as the compiler is $400 otherwise IIRC. If it's for
real (time==money) use it's worth every penny as it compiles code roughly
three times faster than gcc :)

On Windows MSVC is free IIRC as long as you are a student or for non
commercial use (as above I only vaguely remember the terms) though they only
provide you with access to a non optimizing version of the compiler. MSVC
has a nice IDE and debugger so you might want to give that a try.

BTW, cross platformness and nifty template tricks are usually mutually
exclusive - at least in my experience. Michael Vance @ TreyArch should be
able to tell a lot of horror stories ;)

-- Daniel, Epic Games Inc.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of Matt
Davies
Sent: Tuesday, December 11, 2001 4:36 AM
To: gam...@li...
Subject: [GD-Linux] ANSI/ISO C++


Hi,

Is there any free compilers for Linux that supports the full ANSI/ISO C++
language - which includes template template parameters and partial template
specialisation.  Does GCC support them yet?  I need a compiler for Windows
as well.  Borland C++ 5.5 seems to do the job but I've had no luck making it
work with the Turbo Debugger.  Perhaps someone can provide me with help
there?

BTW, does anyone know whats happened to the SWENG mailing list.  I've sent
some messages out but I haven't received any.  Is it down?

Best regards,


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com

[GD-Linux] ANSI/ISO C++

[Matt D. <ma...@co...>]

Hi,

Is there any free compilers for Linux that supports the full ANSI/ISO C++
language - which includes template template parameters and partial template
specialisation.  Does GCC support them yet?  I need a compiler for Windows
as well.  Borland C++ 5.5 seems to do the job but I've had no luck making it
work with the Turbo Debugger.  Perhaps someone can provide me with help
there?

BTW, does anyone know whats happened to the SWENG mailing list.  I've sent
some messages out but I haven't received any.  Is it down?

Best regards,


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com

Re: [GD-Linux] Algorithm help

[Jan E. <ch...@in...>]

On Mon, 26 Nov 2001, Stephen J Baker wrote:

>
>> I have a 3D scene in which a "camera" glides over the terrain in normal
>> FPS mode. The terrain is a normal 2D matrix of y-values, with the x- and
>> z-coordinates spread evenly, i.e. a perfectly regular matrix. This works
>> fine, and I take the y-coordinate for the camera (height above the
>> terrain) from the matrix. So, if the camera is at (x,z) I get the camera
>> height from something like this:
>>
>>     height = map [int(x)][int(y)]
>
>Well, there are two answers to your problem.
>
>Obviously, you need to INTERPOLATE the 'height posts' in your
>grid to get the camera height.

Yes, this was the way to do it, and after some thinking it's also the
obvious way. Thank you for the kind help and the code (which I used parts
of).

The movement is still a little bit jerky. I think I have an indexing
bug somewhere in my code, but it's a lot smoother than it was before.

Well, this must be one of the more perverse projects, as I do this
experiment in Python. Not the fastest thing in the world, but very nice to
work with.

	Chakie

-- 
         In the Beginning there was nothing, which exploded.
                                        -- Terry Pratchett, Lords and Ladies

Re: [GD-Linux] Reinitializing the heap

[Steve B. <sjb...@ai...>]

"Josh Adams" wrote:

> The easiest way to get this behaviour would be to write a local
> allocator which offered those semantics.  I did this at one point
> with a head implementation that allowed watermarking.  Basically you
> could make watermarks at various times, and then free all
> still-valid allocations back to the named watermark (yeah, single
> threaded with linear process flows).

That seems dangerous beyond sanity.

If you use *any* library functions, you could end up freeing memory
it still has pointers to...your graphics library, even (in principal) the
C standard library could be using heap memory that you don't know about.

Suppose there was something like:

  void some_glibc_function ()
  {
    static char *pointer = NULL ;

    if ( pointer == NULL )
    {
      pointer = malloc ( 100 ) ;
      precompute_something () ;
    }

    ...do something using the precomputed data...
  }

...that would fail disasterously if you did what you propose.

This kind of dirty trick is common in the games console business - but
those don't have operating systems (well, not that matter) and you can
do this kind of disgusting thing and get away with it.

"Ryan C Gordon" replied:

>> That being said, someone needs to speak reasonably and say that all of
>> this is interesting, but bad, bad practice.

I just flat out don't think it'll work.

>> Shrugging your shoulders and
>> saying "hey, it's a video game after all, so who cares if it's got leaks
>> in the first place and I choose a non portable hack to fix them in the
>> second?" is not only shortsighted, but it says a lot about game coding
>> mentalities that are rampant in the industry.

Yep.  A memory leak is a **BUG** and you should determinedly seek it out
because you don't know what *all* of it's side-effects are until you've
found it.  What might have the obviously visible side effects of leaking
memory might also be corrupting something...who knows?

>> I would recommend that you attack memory problems with the correct tools:
>> dmalloc, ElectricFence, mcheck(), etc. It may save your sanity later on.

Yes.
 
----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [GD-Linux] Reinitializing the heap

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

> The easiest way to get this behaviour would be to write a local
> allocator which offered those semantics.  I did this at one point
> with a head implementation that allowed watermarking.  Basically you
> could make watermarks at various times, and then free all
> still-valid allocations back to the named watermark (yeah, single
> threaded with linear process flows).

For the truly brave, along those lines:
  http://www.gnu.org/manual/glibc-2.2.3/html_chapter/libc_3.html#SEC34

Change the hooks, and you won't even need to change the code that you need
to put in a separate memory "boxcar"...Design functions that flag a given
memory pointer as contained in a given boxcar, set the hooks appropriately
when you want to watch for this, and then, when the questionable code is
done, just detach that whole boxcar from the metaphorical memory train and
put the original hooks back.

This could also be a poor man's garbage collector, if you've got leaky
code, and, if coded right, won't add too much overhead to the existing
program.

That being said, someone needs to speak reasonably and say that all of
this is interesting, but bad, bad practice. Shrugging your shoulders and
saying "hey, it's a video game after all, so who cares if it's got leaks
in the first place and I choose a non portable hack to fix them in the
second?" is not only shortsighted, but it says a lot about game coding
mentalities that are rampant in the industry.

I would recommend that you attack memory problems with the correct tools:
dmalloc, ElectricFence, mcheck(), etc. It may save your sanity later on.

--ryan.

Re: [GD-Linux] Reinitializing the heap

[J C L. <cl...@ka...>]

On Tue, 27 Nov 2001 13:20:39 -0800 
Josh Adams <ja...@se...> wrote:

> Hey all, Is it possible to reinitialize the standard libc malloc
> heap during runtime?  I would rather do this than try to make sure
> every last bit of memory is cleaned up (it's a game after all).

Not portably/reliably, well, not without just dropping your current
context via something like an exec() which does the right VM things.
If you can show your context out in a shm block this can work fairly
nicely (you get recycled file handles, IPC structures etc as well
which can be useful).

> I'm looking for anything from an externed function I can call
> (like __malloc_init) or getting the 'top' of the heap and setting
> it to 0 or something like that.

The easiest way to get this behaviour would be to write a local
allocator which offered those semantics.  I did this at one point
with a head implementation that allowed watermarking.  Basically you
could make watermarks at various times, and then free all
still-valid allocations back to the named watermark (yeah, single
threaded with linear process flows).

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

[GD-Linux] Reinitializing the heap

[Josh A. <ja...@se...>]

Hey all,

Is it possible to reinitialize the standard libc malloc heap during runtime?
I would rather do this than try to make sure every last bit of memory is
cleaned up (it's a game after all).

I'm looking for anything from an externed function I can call (like
__malloc_init) or getting the 'top' of the heap and setting it to 0 or
something like that.

Any hints would be greatly appreciated,
Josh

--
Josh Adams [ja...@se...]
Senior Programmer, Founder
Secret Level [www.secretlevel.com]

Re: [GD-Linux] Algorithm help

[Eero P. <epa...@ko...>]

Jan Ekholm wrote:

 
> I have a 3D scene in which a "camera" glides over the terrain in normal
> FPS mode. The terrain is a normal 2D matrix of y-values, with the x- and
> z-coordinates spread evenly, i.e. a perfectly regular matrix. This works
> fine, and I take the y-coordinate for the camera (height above the
> terrain) from the matrix. So, if the camera is at (x,z) I get the camera
> height from something like this:
> 
> 	height = map [int(x)][int(y)]
> 
...........
> So if the camera is at X the idea above gives me that that camera should
> have the height at point A in the map as long as the camera is in that
> tile. If it moves on tile to the right it gets the height of point B. This
> gives a camera that is jerky, especielly if the heights in A,B,C and D
> differ even slightly. The correct way would thus be to interpolate the
> heights of all the points somehow, so that the camera would "flow"
> smoothly over the tile. Any ideas on how to do this? If the tiles were
> much smaller that problem would not exist, but my tiles are quite big.
> 
> I've tried to STFW, but I don't really know what to look for. Anyone got
> some pointers to some nice math that I could use, or have done this
> before?


If I understood you question correctly (and also the FLA)....

The simplest solution I guess is to use bilinear interpolation.
Google can help with the details.



			Eero

[GD-Linux] Algorithm help

[Jan E. <ch...@in...>]

Hi all,

I have a small problem that my brain just can't work out. Being pretty
useless at maths I thought about asking here, maybe someone has done
something similar.

I have a 3D scene in which a "camera" glides over the terrain in normal
FPS mode. The terrain is a normal 2D matrix of y-values, with the x- and
z-coordinates spread evenly, i.e. a perfectly regular matrix. This works
fine, and I take the y-coordinate for the camera (height above the
terrain) from the matrix. So, if the camera is at (x,z) I get the camera
height from something like this:

=09height =3D map [int(x)][int(y)]

This of course gets me the height of the lower corner of the current
"tile". Some helpful ascii art:


         |D       |C       |
       --+--------+--------+--
         |        |        |
         |    X   |        |
         |        |        |
         |A       |B       |
       --+--------+--------+--
         |        |        |
         |        |        |
         |        |        |
         |        |        |
       --+--------+--------+--
         |        |=A0       |

So if the camera is at X the idea above gives me that that camera should
have the height at point A in the map as long as the camera is in that
tile. If it moves on tile to the right it gets the height of point B. This
gives a camera that is jerky, especielly if the heights in A,B,C and D
differ even slightly. The correct way would thus be to interpolate the
heights of all the points somehow, so that the camera would "flow"
smoothly over the tile. Any ideas on how to do this? If the tiles were
much smaller that problem would not exist, but my tiles are quite big.

I've tried to STFW, but I don't really know what to look for. Anyone got
some pointers to some nice math that I could use, or have done this
before?

Regards,
    Chakie

--=20
                 "Students?" barked the Archchancellor.
    "Yes, Master. You know? They're the thinner ones with the pale faces?
  Because we're a university? They come with the whole thing, like rats --"
                                         -- Terry Pratchett, Moving Picture=
s

RE: [GD-Linux] signals and exceptions

[Michael R. <mi...@sw...>]

I suspect what is needed may be found in GNU binutils, but you'll have to do
some hunting.

See demangle.h for cplus_demangle, anyhow.

regards,

~m

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of Mads
> Bondo Dydensborg
> Sent: Saturday, November 17, 2001 2:55 AM
> To: D. Stimits
> Cc: gam...@li...
> Subject: Re: [GD-Linux] signals and exceptions
>
>
> On Fri, 16 Nov 2001, D. Stimits wrote:
>
> > Now maybe someone could answer this; I added -rdynamic and it improved
> > the output by naming functions, but the arguments to the function were
> > still not useful, they still look like offsets rather than what my
> > sample had (like calling a function with an int of 1, then 2, then 3, so
> > on...and showing up as something far different). Is there some way to
> > expand on this debugging to get even more information, such as local
> > variable values and formatted (meaningful) argument call values?
>
> I am sorry I do not know the answer to your question. gdb can do this, so
> I suppose there is a way to do it, although I do not know if there are any
> built in functions you can use.
>
> I did write a simple perl script to demangle c++ names and get file:line
> information, which follows here:

Re: [GD-Linux] signals and exceptions

[Mads B. D. <ma...@ch...>]

On Fri, 16 Nov 2001, D. Stimits wrote:

> Now maybe someone could answer this; I added -rdynamic and it improved
> the output by naming functions, but the arguments to the function were
> still not useful, they still look like offsets rather than what my
> sample had (like calling a function with an int of 1, then 2, then 3, so
> on...and showing up as something far different). Is there some way to
> expand on this debugging to get even more information, such as local
> variable values and formatted (meaningful) argument call values?

I am sorry I do not know the answer to your question. gdb can do this, so
I suppose there is a way to do it, although I do not know if there are any
built in functions you can use.

I did write a simple perl script to demangle c++ names and get file:line
information, which follows here:

#!/usr/bin/perl -w
 
# Get the program name for the addr2line program
$program = shift(@ARGV);
 
if (!defined $program || "" eq $program) {
    print STDERR "Usage: $0 <program>\n";
    exit 1;
}
 
while(<>) {
    if (m/\((.+)\+0x[[:xdigit:]]+\) \[(0x[[:xdigit:]]+)\]/) {
        $function = `c++filt $1`;
        chop($function);
        $line = `addr2line -e $program $2`;
        chop($line);
        print "$function ($line)\n";
    } else {
        print STDERR "Warning: No match for $_";
    }
}

Maybe it can be useful to you (or someone else).

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
A few months ago, I was talking to Raymond on the phone, when I called a
computer criminal a "hacker" instead of a "cracker." He hung up on me.

                               - John Marcotte

Re: [GD-Linux] signals and exceptions

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

Daniel Vogel wrote:
> 
> > I forgot to add, that you need to put the -rdynamic flag on you linker
> > line, quite possible last on the line, to make it work.
> 
> I use -export-dynamic or -Qoption,link,--export-dynamic for icc and it
> doesn't result in a meaningful backtrace. -rdynamic should be equivalent
> to -export-dynamic on Linux, right?
> 
> - Daniel Vogel, Programmer, Epic Games Inc.
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux

If I recall correctly, rdynamic is symbol support for relocateable code
in general. Normally you wouldn't need it except when dynamically
linking; I suspect it performs some kind of utility aid for the
debugging functions that works in just the same way as dlopen would use
it.

Now maybe someone could answer this; I added -rdynamic and it improved
the output by naming functions, but the arguments to the function were
still not useful, they still look like offsets rather than what my
sample had (like calling a function with an int of 1, then 2, then 3, so
on...and showing up as something far different). Is there some way to
expand on this debugging to get even more information, such as local
variable values and formatted (meaningful) argument call values?

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