In article <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> MY platform is Linux, RH3
>
> I forgot to mention that, the GDB is showing some other file too.
> Actually, I am working on a huge compiler that creates an exectuable.
> I am running the executable, which is
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> This did not work.
What didn't work?
You probably should read this:
http://catb.org/~esr/faqs/smart-questions.html
> When I set the breakpoint to the hardware address
> of the function , it still shows me the wrong address.
If it shows you the
No Paul ( May I use this as your name )
This did not work. When I set the breakpoint to the hardware address
of the function , it still shows me the wrong address.
___
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listi
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> MY platform is Linux, RH3
There was a RedHat-3.0.3 release (dated May 1st, 1996).
I very much doubt that that's your platform.
More likely you are using 'Red Hat Enterprise Linux v3', which is
usually abbreviated RHEL-3.
> I forgot to mention th
@John ,
No, The ctor is not inlined.
Also, I set a breakpoint on that file and line no. But it still shows
me a wrong file with a wrong file number.
I did not try with a diff gdb version.
I am using
GNU gdb Red Hat Linux (6.3.0.0-0.30.1rh)
___
help-gp
MY platform is Linux, RH3
I forgot to mention that, the GDB is showing some other file too.
Actually, I am working on a huge compiler that creates an exectuable.
I am running the executable, which is a pure object code and will some
time call, the ctors. Now the solution to compile all the
problem
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> I have problem debugging the constructor of a class. The debugger does
> not step into it, it gets into some other line number,
This is usually the result of buggy compiler (incorrect line info
in the object), of optimization (inlining in particul
On Sun, 2007-09-23 at 18:43 +, [EMAIL PROTECTED] wrote:
> I have problem debugging the constructor of a class. The debugger does
> not step into it, it gets into some other line number.
The following is an assumption, since the call to the constructor is
done in assembly the debugger has noway
