Martin Olsson | 1 May 2012 22:36
Picon

-ggdb3 -gdwarf-4 but "info macro BLAH" still doesn't work?

Hello,

In a small test app built with -g3 I can print values of macros inside 
gdb by doing "info macro MYMACRONAME", however in a larger application 
I cannot get it to work despite passing the same -g3 and using the 
same gdb command. Just to be sure, I tried turning off stuff like 
pre-compiled headers etc in the large app but I still can't get the 
macro values to print correctly. In the large app, what I see is:

(gdb) info macro MYMACRONAME
The symbol `MYMACRONAME' has no definition as a C/C++ preprocessor macro
at ../../platforms/linux/src/main.cpp:263

In both cases gdb "info source" reports "Includes preprocessor macro 
info."
and also "Compiled with DWARF 2 debugging format."

For the large app readelf also reports the macro I'm testing as 
present (so I'm assuming the gcc end is doing the right thing):

$ readelf -wm binary | grep MYMACRONAME
  DW_MACINFO_define - lineno : 12 macro : MYMACRONAME 4096

FWIW; I'm using ubuntu 12.04 LTS which means I got gcc 
4:4.6.3-1ubuntu5 and gdb 7.4-2012.02-0ubuntu2. I've also tried 
building with "-ggdb3 -gdwarf-4" but I still can't get values of 
macros and oddly gdb then still reports "Compiled with DWARF 2 
debugging format", which was a bit weird?

Also if I do "info macros" then I get nothing printed at all.
(Continue reading)

Matt Rice | 1 May 2012 23:56
Picon

Re: -ggdb3 -gdwarf-4 but "info macro BLAH" still doesn't work?

On Tue, May 1, 2012 at 1:36 PM, Martin Olsson <mnemo <at> minimum.se> wrote:
> Hello,
>
> In a small test app built with -g3 I can print values of macros inside gdb
> by doing "info macro MYMACRONAME", however in a larger application I cannot
> get it to work despite passing the same -g3 and using the same gdb command.
> Just to be sure, I tried turning off stuff like pre-compiled headers etc in
> the large app but I still can't get the macro values to print correctly. In
> the large app, what I see is:
>
> (gdb) info macro MYMACRONAME
> The symbol `MYMACRONAME' has no definition as a C/C++ preprocessor macro
> at ../../platforms/linux/src/main.cpp:263

the important part here I think is the:
at ../../platforms/linux/src/main.cpp:263

are you sure that MYMACRONAME is included and defined
at that point in the main.o file? info macro only does macros for the
place the program is currently executing at.

i see you are not getting the error message from the function
macro_inform_no_debuginfo so it seems there is a 'macro scope'.

> In both cases gdb "info source" reports "Includes preprocessor macro info."
> and also "Compiled with DWARF 2 debugging format."
>
> For the large app readelf also reports the macro I'm testing as present (so
> I'm assuming the gcc end is doing the right thing):
>
(Continue reading)

Doug Evans | 3 May 2012 00:13
Picon
Favicon

Symbol Handling improvements

[bcc gdb-patches, just to make sure it reaches everyone]

Hi.
fyi, I have started a page to collect issues related to symbol
handling, debug info, etc. and to list ideas people are thinking
about.

I don't have any specific actions to take yet.
It's just a beginning.

http://sourceware.org/gdb/wiki/SymbolHandling

Comments welcome.

Doug Evans | 3 May 2012 00:16
Picon
Favicon

Re: Symbol Handling improvements

On Wed, May 2, 2012 at 3:13 PM, Doug Evans <dje <at> google.com> wrote:
> [bcc gdb-patches, just to make sure it reaches everyone]
>
> Hi.
> fyi, I have started a page to collect issues related to symbol
> handling, debug info, etc. and to list ideas people are thinking
> about.
>
> I don't have any specific actions to take yet.
> It's just a beginning.
>
> http://sourceware.org/gdb/wiki/SymbolHandling
>
> Comments welcome.

Blech.  I guess qmail didn't like the bcc, it bounced as spam.

Tomasz Grobelny | 3 May 2012 05:23
Favicon

sun compiler and gdb

Hi all,
Should it be possible to debug C++ programs compiled using sun compiler
using GDB? If so which debug format should I use? Which versions of the
compiler/gdb support such a scenario? Currently the situation looks like
this (which does not look very promising):

> /opt/solstudio12.2/bin/CC -V
CC: Sun C++ 5.11 SunOS_i386 2010/08/13
usage: CC [ options ] files.  Use 'CC -flags' for details
> /opt/solstudio12.2/bin/CC -g -xdebugformat=dwarf test.cpp
> gdb -q ./a.out
Reading symbols from /full/path/to/my/a.out...done.
(gdb) break fun
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x13b33 [in
module /full/path/to/my/a.out]
(gdb) break main
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x13b33 [in
module /full/path/to/my/a.out]
(gdb) run
Starting program: /full/path/to/my/a.out
[Thread debugging using libthread_db enabled]
hello world
[Inferior 1 (process 9412    ) exited normally]
(gdb) quit
> uname -a
SunOS solac1 5.10 Generic_137138-09 i86pc i386 i86pc
> 

gdb version is 7.4.1
Any ideas what is wrong here?
(Continue reading)

Sergio Durigan Junior | 3 May 2012 08:49
Picon
Favicon

Re: sun compiler and gdb

On Thursday, May 03 2012, Tomasz Grobelny wrote:

> Hi all,
> Should it be possible to debug C++ programs compiled using sun compiler
> using GDB? If so which debug format should I use? Which versions of the
> compiler/gdb support such a scenario? Currently the situation looks like
> this (which does not look very promising):

Indeed.  In a quick search using Google, I found some links reporting
that the compiler is kind of broken, probably when it comes to DWARF
generation.  Anyway, by reading this link:

    http://netbeans.org/bugzilla/show_bug.cgi?id=89876

especifically in comment #8, I saw that you can try enabling some
options in your C++ compiler:

    -Qoption cg -h_gcc -xO0 -g

Also, I saw that passing `-xs' to the compiler might help a bit.  But
overall, AFAIU, you don't have many options here, unfortunately.
However, I'm definitely not an expert in the platform, so maybe someone
more experienced will show up and help you further.

Good luck.

--

-- 
Sergio

(Continue reading)

xgsa | 3 May 2012 08:55
Picon
Favicon

Re: Memory Dump

Hi,

I am not sure, but it seems massif (the tool from the valgrind 
toolchain) could help you.

P.S. However the question is still interesting - is there a possibility 
to solve the problem with gdb? Could someone answer it?

Anton.

-------- Original message --------
>
> Hi,
>
> I wonder whether it is possible to dump all the objects created in the memory at the moment with GDB (I am on v7.0.1).
>
> What I am trying to achieve is to identify which types of objects take up most of the memory at the moment.
>
> Valgrind doesn't catch it and so I believe that it is some logical bug in my code that keeps creating the
objects and free all of them at the end (i.e. program terminated).
>
> Thanks in advance.
>
>
> Cheers,
> Hei
>
>

(Continue reading)

jiji vinitha | 3 May 2012 09:38
Picon

Unstable GDB results due to change in dl_debug_state()

Hi All,

  I have been testing gdb-7.2 in an smp kernel in ARM cortex-A9 environment.
  I am getting more than 1000 additional failures.

It appears that this happens only in case of SMP kernel.
On uP kernel any additional unexpected failures are not reported.

The testsuite behaviour appears to be unstable in SMP kernel environment.
For eg, the testcase ending-run.exp it shows unstable behaviour as shown below.

 * The testcases passes sometimes as shown below
{{{
Running ./gdb.base/ending-run.exp ...

                === gdb Summary ===

# of expected passes            19
# of unsupported tests          1
}}}

 * Sometimes it fails as shown below
{{{
Running ./gdb.base/ending-run.exp ...
FAIL: gdb.base/ending-run.exp: run (the program exited)
FAIL: gdb.base/ending-run.exp: clear worked
FAIL: gdb.base/ending-run.exp: cleared bp at line before routine
FAIL: gdb.base/ending-run.exp: Cleared 2 by line
FAIL: gdb.base/ending-run.exp: Clear 2 by default
FAIL: gdb.base/ending-run.exp: all set to continue (didn't clear bps)
(Continue reading)

Tomasz Grobelny | 3 May 2012 15:59
Favicon

Re: sun compiler and gdb

On Thu, 03 May 2012 03:49:41 -0300, Sergio Durigan Junior
<sergiodj <at> redhat.com> wrote:
> On Thursday, May 03 2012, Tomasz Grobelny wrote:
> 
>> Hi all,
>> Should it be possible to debug C++ programs compiled using sun compiler
>> using GDB? If so which debug format should I use? Which versions of the
>> compiler/gdb support such a scenario? Currently the situation looks
like
>> this (which does not look very promising):
> 
> Indeed.  In a quick search using Google, I found some links reporting
> that the compiler is kind of broken, probably when it comes to DWARF
> generation.  Anyway, by reading this link:
> 
>     http://netbeans.org/bugzilla/show_bug.cgi?id=89876
> 
> especifically in comment #8, I saw that you can try enabling some
> options in your C++ compiler:
> 
>     -Qoption cg -h_gcc -xO0 -g
> 
> Also, I saw that passing `-xs' to the compiler might help a bit.  But
> overall, AFAIU, you don't have many options here, unfortunately.
> However, I'm definitely not an expert in the platform, so maybe someone
> more experienced will show up and help you further.
> 
> Good luck.
> 

(Continue reading)

Aurelian Melinte | 3 May 2012 16:17
Picon

Re: Memory Dump


> Hi,
> 
> I am not sure, but it seems massif (the tool from the valgrind 
> toolchain) could help you.
> 
> P.S. However the question is still interesting - is there a possibility 
> to solve the problem with gdb? Could someone answer it?

The only way I know is to write an interposition library to hook
malloc()/memalign()/realloc()/free()/mmap()/munmap()/sbrk() and maybe more.

An easier alternative might be mcheck() - depending what exactly you are looking for.

Otherwise, wrap malloc() and friends within your own functions (xmalloc()) and use only these inside your
program, etc.

Regards,
a.

> 
> Anton.
> 
> -------- Original message --------
> >
> > Hi,
> >
> > I wonder whether it is possible to dump all the objects created in the
> memory at the moment with GDB (I am on v7.0.1).
> >
(Continue reading)


Gmane