backtrace and demangling symbols at runtime
Hi..
I'm using __cxxabiv1::__cxa_demangle() function to demangle the symbols
obtained by backtrace_symbols(). This works almost fine. However, can
somebody explain what does the symbol __gxx_personality_v0 mean?
Consider this example:
class A
{
public:
A() {}
};
class B
{
public:
B() {}
private:
A a;
};
int main()
{
B b;
return 0;
}
Note that class A is implemented in a shared library linked dynamically
to my example. I see the backtrace from A's constructor, but I don't
see anything about B, the backtrace looks like this:
(stuff called from A's constructor)
A::A
__gxx_personality_v0
__gxx_personality_v0
__libc_start_main
__gxx_personality_v0
So my problem is I don't see where A is created from.
Can somebody enlighten me?
Thanks.
___
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
Re: backtrace and demangling symbols at runtime
Bernd Strieder napísal(a): > Probably due to inlining. You have all the code in one compilation unit. > If a constructor only calls another constructor, only that call might > be left after inlining. There are other optimization techniques with a > great influence on the call stack, e.g. tail call optimization, and I > don't know how well backtrace does with all of it. In my experience > even gdb can produce quite confusing displays on optimized code, > although it probably has better chances to get reasonable results. > > Try compiling with -O0, or try different compilation units, or add code > to print messages. > I don't have any optimization on, but I tried with -O0 anyway, I also moved class B to another compilation unit and added some std::cout stuff to B's constructor. Yet the backtrace remains the same. ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
Re: backtrace and demangling symbols at runtime
> Try using gdb instead. I do, I just need to know the backtrace at runtime. ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
Re: Amazing Performance Difference between vec[] and iterators
Paulo Matos wrote: > Hi all, > > I've wanted to know if there was any performance difference between > using: > for(vector::const_iterator it = v.begin(); it != v.end(); ++it) > > and > > for(unsigned int k = 0; k < v.size(); ++k) > > and it seems there is with gcc 4.1.1, using -O3, the later is almost > two times slower. > The program is at: > http://sat.inesc-id.pt/~pocm/archive/vec.cc > Then do: > $ g++ -O3 vec.cc -o vec-iter -DITER > $ g++ -O3 vec.cc -o vec > > I got these times: > $ time ./vec > 5030 elements in array. > sum: 27665 > > real0m7.123s > user0m7.108s > sys 0m0.008s > > $ time ./vec-iter > 5030 elements in array. > sum: 27665 > > real0m4.699s > user0m4.672s > sys 0m0.020s > > Any comments on these results? They don't seem intuitive to me. Why the > difference? just guessing.. could that be the overhead of calling size() and operator[] each time? try to store the size() to a local variable before the for loop.. also see the implementation of size() and operator[] in bits/stl_vector.h > > Cheers, > > Paulo Matos ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
Re: g++
> I would like to install the recent g++ locally in my home directory > as a non-privileged user for testing purposes. It such an installation > possible, having another version of g++ running globally? > It is possible. ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
Re: allocate 2d pointer. is ths a bug ?
> 5char** str; > 6 > 7str[0] = new char[5]; > 8str[1] = new char[5]; > 9 I believe the result is "undefined behavior", so the program might do anything it wants.. ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
Re: allocate 2d pointer. is ths a bug ?
h wrote: > Thanks Mehturt. > > but, it works through g++ on Cygwin and GNU/Linux machine without MS-VC++ > 6.0 on win32 machine. > i know i've attached code are has a problem. > Undefined behavior is undefined behavior, it might work, it might not, it might format your harddrive.. Try to use a debugging application, such as valgrind, to see where your errors are.. ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
Re: Static link trouble
Salvatore Di Fazio napísal(a): > Paul Pluzhnikov wrote: > > > I also want it to run on systems that don't have libstdc++ > > installed at all (this could be the case on a "production server", > > which often doesn't have g++ installed). > > That's right ;) I usually distribute libstdc++.so and set LD_LIBRARY_PATH to include it. ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
always true warning
Hi, is it possible to turn off -Walways-true warning for certain comparison? I have a template with parameter of integral type, which can be both signed and unsigned and I'm testing the value for <0.. With -Wall (which I'm using by default) I always get a warning this comparison is always true when I use unsigned type as a parameter.. Are there any workarounds? Thanks m ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
Re: always true warning
Bernd Strieder wrote: > The clean way means (partially) specializing your template, and remove > the comparisions from the code for unsigned. If your template itself is > too large, you could perhaps forward the member functions with those > comparision to other template functions, which you could specialize > more easily. I was thinking about this, but is it possible at all without having specialize for all types? (char, int, long, long long) ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
Re: always true warning
Bernd Strieder wrote: > > I think I would prefer the warning in your case, if there are no other > reasons for the template hackery, then it should not be done. If you > have the same problem in more instances, then creating a custom traits > class might be helpful, i.e. make general_version to a class and put > the things depending on the integer type into it as typedefs or > whatever, just extending the idea. Maybe you could use existing traits > classes, like those from boost, I think they include signedness. > What I did is I implemented template fn bool isnegative() which is used instead of <0. This fn returns false in general and is specialized for signed types so that it returns <0. > I'm probably not reachable until next year, so I have to hope there are > competent people to help you still reading, if you have more questions. Happy new year ;) m ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
