gmane.comp.gdb.devel

problems with async mode using user-defined or python command sequences

Tim Black — 2012-05-23T18:36:43

I'm using gdb 7.4.1 on embedded powerpc target and 2.6.32.28 kernel to
perform some analysis on my multi-threaded C++ program that uses
pthreads. My end goal was to script gdb with python to automate some
common analysis functions, and create a crude profiler by sampling the
stack of the active thread. The problem is that I am finding some
discrepancy in behavior when I run commands individually at the
command line vs. in a gdb user-defined command (or invoking the same
commands via python script). I found a reference to a very similar
problem on this mailing list:
http://sourceware.org/ml/gdb/2009-01/msg00157.html
Although I don't completely follow Pedro's response about the
limitation of async mode, I think he's implying that in async mode,
the relative timing of user-defined command sequences cannot be
trusted. This is what I found empirically.

In both scenarios, I perform the following start-up steps, loading my
program, setting its args, and turning on asynchronous and non-stop
debugging modes, then running the program in the background:

(gdb) file myprogram
(gdb) set args --interface=eth0 --try-count=0
(gdb) set target-async on
(gdb) set pagination off
(gdb) set non-stop on
(gdb) run &

At this point, if I manually issue "interrupt" and then "info threads"
commands, I see the list of all threads running except one that got
stopped. Then I can continue & and repeat to my hearts content, it
works consistently. When stopped, I can inspect that thread's stack
frames and all is well.

However, if instead I put these commands into a user-defined gdb command:

(gdb) define foo
(gdb) interrupt
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.

I believe the error msg is caused by the "continue &" command, because
the preceding "interrupt" did not stop any threads (yet). I thought
this was a problem inherent to the asynchronous gdb commanding, so I
inserted an absurdly long wait after the interrupt command and got the
same behavior:

(gdb) define foo
(gdb) interrupt
(gdb) shell sleep 5
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.

With or without the sleep command, I can always issue the manual CLI
commands and the threads get stopped correctly.

Similarly, I get the same results sourcing a python script to do the
thread perusal:

import gdb, time

gdb.execute("file myprogram")
gdb.execute("set args --interface=eth0 --try-count=0")
gdb.execute("set target-async on")
gdb.execute("set pagination off")
gdb.execute("set non-stop on")
gdb.execute("run &")
time.sleep(5)
gdb.execute("interrupt")

# here, I inspect threads via gdb module interface
# in practice, they're always all running bc the program never got interrupted
for thread in gdb.selected_inferior().threads():
    print thread.is_running(),

gdb.execute("continue &")

I get the same result even if I specify from_tty=True in the
gdb.execute calls. Also, if I use continue -a it suppresses the error
string but does not help otherwise bc the interrupt call still doesn't
work.

So... is this:

    * cockpit error? Is there something that I'm omitting or doing
incorrectly, given what I'm trying to accomplish? Should this work, or
do I have to use GDB/MI to asynchronously "drive" gdb like this?
    * a timing problem? Maybe invoking shell sleep (or python
time.sleep()) doesn't do what I assume it would, in this context.
    * a gdb problem?

Thanks.

Re: Is there any mechanism in GDB to print memory allocation pattern in a core dump file

santoshp — 2012-05-23T17:18:30

The application is a C++ application running on Linux (RHEL 5.7 x86_64). It
uses a private memory allocator (variation of ptmalloc). The gdb-heap link
says it works for python objects and work for c++ is under process. Can I
use the gdb-heap ?

Thanks,
Santosh

Nothing built in, but there is gdb-heap, if you're on a system using
glibc.

https://fedorahosted.org/gdb-heap/

Tom

Re: Is there any mechanism in GDB to print memory allocation pattern in a core dump file

Tom Tromey — 2012-05-23T15:13:18

Santosh> I got a crash for which the size of the core file is little
Santosh> bigger i.e.  ~9GB. Initial impression is that there might be
Santosh> some memory leaks in the process as the size is bugger than the
Santosh> usual size. Is there any mechanism in GDB/Linux I can find out
Santosh> the memory allocation pattern in the core file?  e.g. There is
Santosh> a tool debug diag in Windows which can do this nicely from dump
Santosh> file.

Nothing built in, but there is gdb-heap, if you're on a system using
glibc.

https://fedorahosted.org/gdb-heap/

Tom

Is there any mechanism in GDB to print memory allocation pattern in a core dump file

santoshp — 2012-05-23T12:32:57

Hi All,
I got a crash for which the size of the core file is little bigger i.e.
~9GB. Initial impression is that there might be some memory leaks in the
process as the size is bugger than the usual size. Is there any mechanism in
GDB/Linux I can find out the memory allocation pattern in the core file?
e.g. There is a tool debug diag in Windows which can do this nicely from
dump file.

Any pointers will be appreciated.

Thanks,
Santosh

Re: Will therefore GDB utilize C++ or not?

2012-05-22T18:03:41

It's a NetBSD/MIPS64 derivative embedded system.  No other secondary storage for code.  Threading support is needed.  (That doesn't add much.)  I don't currently have multi-inferior support, although I've thought about adding that.

paul

On May 21, 2012, at 1:57 PM, Jan Kratochvil wrote:

Re: [PATCH] MIPS/sim: Fix build breakage

Maciej W. Rozycki — 2012-05-22T14:26:19


 Yep, no build failure for mips-sde-elf anymore.

  Maciej

Re: Gdb crashing or not attaching in Netbeans

2012-05-22T10:55:02

  Finally I got logs!
I'm asking for help in understanding what is happening.
First is a correct log, as to say a log of a working debugging session up to 
the first break point.
Then a log of a crashed debugging session, from which the debugger never 
recovers (closing the IDE, restarting the computer, nothing solves the debugger 
crash. Just clearing the IDE user settings folder).

So here is a working log.
=thread-group-added,id="i1"
~"GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04\n"
~"Copyright (C) 2012 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.
html>\nThis is free software: you are free to change and redistribute it.
\nThere is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"
\nand \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-linux-gnu\".\nFor bug reporting 
instructions, please see:\n"
~"<http://bugs.launchpad.net/gdb-linaro/>.\n"
&"/home/erupter/.gdbinit: No such file or directory.\n"
(gdb) 
2-list-features
3-gdb-set print repeat 0
4-gdb-set backtrace limit 1024
5-gdb-set print elements 0
6-environment-directory ".:/usr/local/include/player-3.1:
/usr/local/include/Stage-4.1"
7-file-exec-and-symbols  "/home/erupter/NetBeansProjects/PlayerStage 
Test/dist/Debug/GNU-Linux-x86/playerstage_test"
2^done,features=["frozen-varobjs","pending-breakpoints","thread-info","data-
read-memory-bytes","breakpoint-notifications","ada-task-info","python"]
(gdb) 
3^done
(gdb) 
4^done
(gdb) 
5^done
(gdb) 
&"Warning: /home/erupter/NetBeansProjects/PlayerStage Test/.:
/usr/local/include/player-3.1:/usr/local/include/Stage-4.1: No such file or 
directory.\n"
6^done,source-path="/home/erupter/NetBeansProjects/PlayerStage Test/.:
/usr/local/include/player-3.1:/usr/local/include/Stage-4.1:$cdir:$cwd"
(gdb) 
7^done
(gdb) 
8-file-list-exec-source-file
8^done,line="10",file="main.c",fullname="
/home/erupter/NetBeansProjects/PlayerStage Test/main.c",macro-info="0"
(gdb) 
9cd /home/erupter/NetBeansProjects/PlayerStage Test
10-exec-arguments 
11set environment $LD_LIBRARY_PATH=/usr/local/lib64;/usr/local/lib;/usr/lib;
/usr/lib64
12-break-insert -f "main.c:35"
&"cd /home/erupter/NetBeansProjects/PlayerStage Test\n"
~"Working directory /home/erupter/NetBeansProjects/PlayerStage Test.\n"
9^done
(gdb) 
10^done
(gdb) 
&"set environment $LD_LIBRARY_PATH=/usr/local/lib64;/usr/local/lib;/usr/lib;
/usr/lib64\n"
11^done
(gdb) 
12^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="
0x0000000000401109",func="main",file="main.c",fullname="
/home/erupter/NetBeansProjects/PlayerStage Test/main.c",line="35",times="0",
original-location="main.c:35"}
(gdb) 
13-break-insert -t _start
13^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="
0x0000000000400f60",at="<_start>",times="0",original-location="_start"}
(gdb) 
14-exec-run
=thread-group-started,id="i1",pid="7246"
=thread-created,id="1",group-id="i1"
14^running
*running,thread-id="all"
(gdb) 
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-
x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-
group="i1"
=library-loaded,id="/usr/local/lib64/libplayerc.so.3.1",target-name="
/usr/local/lib64/libplayerc.so.3.1",host-name="/usr/local/lib64/libplayerc.so.
3.1",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/lib/x86_64-linux-gnu/libm.so.6",target-name="/lib/x86_64-
linux-gnu/libm.so.6",host-name="/lib/x86_64-linux-gnu/libm.so.6",symbols-
loaded="0",thread-group="i1"
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-
linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-
loaded="0",thread-group="i1"
=library-loaded,id="/usr/local/lib64/libplayerinterface.so.3.1",target-name="
/usr/local/lib64/libplayerinterface.so.3.1",host-name="
/usr/local/lib64/libplayerinterface.so.3.1",symbols-loaded="0",thread-group="
i1"
=library-loaded,id="/usr/local/lib64/libplayerwkb.so.3.1",target-name="
/usr/local/lib64/libplayerwkb.so.3.1",host-name="/usr/local/lib64/libplayerwkb.
so.3.1",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/lib/x86_64-linux-gnu/libz.so.1",target-name="/lib/x86_64-
linux-gnu/libz.so.1",host-name="/lib/x86_64-linux-gnu/libz.so.1",symbols-
loaded="0",thread-group="i1"
=library-loaded,id="/usr/local/lib64/libplayerjpeg.so.3.1",target-name="
/usr/local/lib64/libplayerjpeg.so.3.1",host-name="
/usr/local/lib64/libplayerjpeg.so.3.1",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/usr/local/lib64/libplayercommon.so.3.1",target-name="
/usr/local/lib64/libplayercommon.so.3.1",host-name="
/usr/local/lib64/libplayercommon.so.3.1",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/usr/lib/libgeos_c.so.1",target-name="/usr/lib/libgeos_c.
so.1",host-name="/usr/lib/libgeos_c.so.1",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/usr/lib/x86_64-linux-gnu/libjpeg.so.8",target-name="
/usr/lib/x86_64-linux-gnu/libjpeg.so.8",host-name="/usr/lib/x86_64-linux-
gnu/libjpeg.so.8",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/usr/lib/libgeos-3.2.2.so",target-name="/usr/lib/libgeos-
3.2.2.so",host-name="/usr/lib/libgeos-3.2.2.so",symbols-loaded="0",thread-
group="i1"
=library-loaded,id="/usr/lib/x86_64-linux-gnu/libstdc++.so.6",target-name="
/usr/lib/x86_64-linux-gnu/libstdc++.so.6",host-name="/usr/lib/x86_64-linux-
gnu/libstdc++.so.6",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/lib/x86_64-linux-gnu/libgcc_s.so.1",target-name="
/lib/x86_64-linux-gnu/libgcc_s.so.1",host-name="/lib/x86_64-linux-gnu/libgcc_s.
so.1",symbols-loaded="0",thread-group="i1"
=breakpoint-modified,bkpt={number="2",type="breakpoint",disp="del",enabled="y",
addr="0x0000000000400f60",at="<_start>",times="1",original-location="_start"}
*stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={addr="
0x0000000000400f60",func="_start",args=[]},thread-id="1",stopped-threads="all",
core="0"
=breakpoint-deleted,id="2"
(gdb) 
15-exec-continue
15^running
*running,thread-id="all"
(gdb) 
No answer for: 14-exec-run
=library-loaded,id="/lib/x86_64-linux-gnu/libnss_files.so.2",target-name="
/lib/x86_64-linux-gnu/libnss_files.so.2",host-name="/lib/x86_64-linux-
gnu/libnss_files.so.2",symbols-loaded="0",thread-group="i1"
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="
y",addr="0x0000000000401109",func="main",file="main.c",fullname="
/home/erupter/NetBeansProjects/PlayerStage Test/main.c",line="35",times="1",
original-location="main.c:35"}
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="
0x0000000000401109",func="main",args=[{name="argc",value="1"},{name="argv",
value="0x7fffffffe4b8"}],file="main.c",fullname="
/home/erupter/NetBeansProjects/PlayerStage Test/main.c",line="35"},thread-id="
1",stopped-threads="all",core="0"
(gdb) 
16-stack-list-frames
16^done,stack=[frame={level="0",addr="0x0000000000401109",func="main",file="
main.c",fullname="/home/erupter/NetBeansProjects/PlayerStage Test/main.c",line="
35"}]
(gdb) 
No answer for: 15-exec-continue
17-stack-list-arguments 1
17^done,stack-args=[frame={level="0",args=[{name="argc",value="1"},{name="
argv",value="0x7fffffffe4b8"}]}]
(gdb) 



And now a non working log.
=thread-group-added,id="i1"
~"GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04\n"
~"Copyright (C) 2012 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.
html>\nThis is free software: you are free to change and redistribute it.
\nThere is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"
\nand \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-linux-gnu\".\nFor bug reporting 
instructions, please see:\n"
~"<http://bugs.launchpad.net/gdb-linaro/>.\n"
&"/home/erupter/.gdbinit: No such file or directory.\n"
(gdb) 
2-list-features
3-gdb-set print repeat 0
4-gdb-set backtrace limit 1024
5-gdb-set print elements 0
6-environment-directory ".:/usr/local/include/player-3.1:
/usr/local/include/Stage-4.1"
7-file-exec-and-symbols  "/home/erupter/NetBeansProjects/PlayerStage 
Test/dist/Debug/GNU-Linux-x86/playerstage_test"
2^done,features=["frozen-varobjs","pending-breakpoints","thread-info","data-
read-memory-bytes","breakpoint-notifications","ada-task-info","python"]
(gdb) 
3^done
(gdb) 
4^done
(gdb) 
5^done
(gdb) 
&"Warning: /home/erupter/NetBeansProjects/PlayerStage Test/.:
/usr/local/include/player-3.1:/usr/local/include/Stage-4.1: No such file or 
directory.\n"
6^done,source-path="/home/erupter/NetBeansProjects/PlayerStage Test/.:
/usr/local/include/player-3.1:/usr/local/include/Stage-4.1:$cdir:$cwd"
(gdb) 
7^done
(gdb) 
8-file-list-exec-source-file
8^done,line="10",file="main.c",fullname="
/home/erupter/NetBeansProjects/PlayerStage Test/main.c",macro-info="0"
(gdb) 
9cd /home/erupter/NetBeansProjects/PlayerStage Test
10-exec-arguments 
11set environment $LD_LIBRARY_PATH=/usr/local/lib64;/usr/local/lib;/usr/lib;
/usr/lib64
12-break-insert -f "main.c:23"
13-var-create - < at > sonar
14-var-update --all-values * 
15-var-create - < at > client
16-var-update --all-values * 
&"cd /home/erupter/NetBeansProjects/PlayerStage Test\n"
17-break-insert -t _start
~"Working directory /home/erupter/NetBeansProjects/PlayerStage Test.\n"
9^done
(gdb) 
10^done
(gdb) 
&"set environment $LD_LIBRARY_PATH=/usr/local/lib64;/usr/local/lib;/usr/lib;
/usr/lib64\n"
11^done
(gdb) 
12^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="
0x000000000040109d",func="main",file="main.c",fullname="
/home/erupter/NetBeansProjects/PlayerStage Test/main.c",line="23",times="0",
original-location="main.c:23"}
(gdb) 
13^done,name="var1",numchild="21",value="0x0",type="playerc_ranger_t *",
has_more="0"
(gdb) 
~"/build/buildd/gdb-7.4-2012.04/gdb/thread.c:613: internal-error: 
is_thread_state: Assertion `tp' failed.\nA problem internal to GDB has been 
detected,\nfurther debugging may prove unreliable.\nQuit this debugging 
session? "
~"(y or n) [answered Y; input not from terminal]\n"
18-var-show-attributes "var1"
~"/build/buildd/gdb-7.4-2012.04/gdb/thread.c:613: internal-error: 
is_thread_state: Assertion `tp' failed.\nA problem internal to GDB has been 
detected,\nfurther debugging may prove unreliable.\nCreate a core file of GDB? 
"
~"(y or n) [answered Y; input not from terminal]\n"
  
This is all being done automatically by Netbeans IDE.
When this happens, I have a "crash notification" from the System notification 
helper too.
Thanks and regards
Claudio Carbone

of

Re: Gdb online docs error?

Yao Qi — 2012-05-22T04:39:32

I get a build on gdb-7.4.1 release on my box.  Both missing files, as
reported, Command-Files.html and GDB_002fMI-Command-Syntax.html are
generated properly.  However, the pdf version got from
http://sourceware.org/gdb/current/onlinedocs/gdb.pdf.gz looks correct.

A lot users reference gdb html doc on sourceware.org, so it is not good
to give them a "page not found" error.  I am happy to help on this, but
don't know what I can do.

Re: [PATCH] MIPS/sim: Fix build breakage

Mike Frysinger — 2012-05-22T01:52:27

so Nick's patch addresses your build failures ?  seems like you guys had some 
overlap, but not entirely ...
-mike

Re: [PATCH] MIPS/sim: Fix build breakage

Maciej W. Rozycki — 2012-05-22T00:11:10


 Nope, just trying to get other work done, and since I did these tweaks 
anyway I decided to share them in case they would help someone else too.
I can see Nick's commited his fixes now, so that settles it.

  Maciej

Re: Will therefore GDB utilize C++ or not?

Matt Rice — 2012-05-21T18:53:50

FWIW, I have an openwrt install on a 4MB flash, and figuring out how
to find enough space for the existing gdbserver was a pain.
to the point where I just made a ramdisk and copied gdbserver to it
when i needed it (which lucky for me wasn't debugging any issue at
boot time/user space worked enough to get gdbserver to its
destination.)

many of these newer openwrt/dd-wrt systems also have usb they can use
to add additional storage.

that is to say, i think regardless of c/c++ gdbserver is possibly too
big for some of these small but not tiny installations or at least on
the cusp of being so, and getting larger, thus a smaller gdbserver
might be warranted regardless of c/c++

Re: Will therefore GDB utilize C++ or not?

Jan Kratochvil — 2012-05-21T16:52:52

With RAII you do not have to write many times in that function that do_cleanup
statement (for multiple cleanup markers), which makes one of the differences.


Jan

Re: Will therefore GDB utilize C++ or not?

Pedro Alves — 2012-05-21T16:27:48



Cleanups are dynamic because they're been crafted that way.
We could tweak cleanups to allow creating them on the stack.

What I meant by not that different, is, that with RAII you get
to write something like (the dumbest version of a RAII object
that supports canceling possible):

class my_raii_thing
{
private:
   whatever_arg *arg; << moral equivalent of the cleanup args.
   bool discarded;

public:
   my_raii_thing (whatever_arg *p) : arg (p), discarded(false)
   {}

   ~my_raii_thing () << moral equivalent of a cleanup function.
   {
      if (!discarded)
        {
          // whatever to release this->arg or something like that.
        }
   }

   void discard ()
   {
      discarded = true;
   }
};

and then do:

  my_raii_thing foo (&whatever_arg);

  if (whatnot)
    {
       whatever_arg.discard();
       return SUCESS;
    }
  }

whereas we now write:

struct cleanup_args
{
  ...
};

void foo_cleanup (void *arg)
{
   // whatever to release this->arg or something like that.
}

and then:

  old_chain = make_cleanup (foo_cleanup, &whatever_arg);

  if (whatnot)
    {
       discard_cleanups (old_chain);
       return SUCESS;
    }
  do_cleanup (old_chain);

But yes, as I've said before elsewhere, give me destructors,
everything else I can live without.  :-)

Basically, whoever understands RAII should understand cleanups.
Not counting the auto-destruction issue, I'm saying that writing
raii classes vs writing cleanup function is mostly syntax sugar.



We could make make_cleanup return a reference to this instead of to the
previous (as Doug suggested not long ago), and tweak cleanups to make
it possible to have them on the stack, making their use follow scope
closer too.

Re: Will therefore GDB utilize C++ or not?

Jan Kratochvil — 2012-05-21T16:59:03

Proposed C++ is not a clear win-win, it is a compromise.  I have found this
discussion gives enough reasons (~from Tom) to consider C++ "very important".

The size has some importance but these mails try to decide whether the size
regressions is globally as important as the C++ benefits for GDB or not.

If the size is important enough then there is also the alternative gdbserver
for bootstraps without C++ (older FSF gdbserver, RDA, #ifdef-out-ed HEAD FSF
gdbserver etc.).  It has also various disadvantages but again I consider them
globally less important than the C++ benefits for GDB.



This is not the specific enough answer I was asking for.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

Pedro Alves — 2012-05-21T16:52:09



I should point out that that question is a bit backwards.  If you can
shrink the storage to save costs, you'll do it.  But obviously you won't
shrink more than what necessary to run your software.
That - shrink storage - is the reasoning why e.g., one feature eglibc
has over glibc, is a way to configure out things that may not be needed
on an embedded system.

Google around for OpenWrt or DD-WRT for example, to find configurations
where 4-32MB flash is common.

Re: Will therefore GDB utilize C++ or not?

Tom Tromey — 2012-05-21T17:20:05

Jan> Could you give specific still used device example where the current
Jan> codebase is OK while the triple gdbserver size is no longer OK?
Jan> All the discussions are still very abstract.

Pedro> I should point out that that question is a bit backwards.  If you can
Pedro> shrink the storage to save costs, you'll do it.  But obviously you won't
Pedro> shrink more than what necessary to run your software.

If size is a critical argument against C++, then it has to be a critical
argument in other cases as well.

I think it is important for us to establish the desirable bounds on the
size of gdbserver, so that we can request this data in future gdbserver
patch reviews.

Tom

Re: Will therefore GDB utilize C++ or not?

Jan Kratochvil — 2012-05-21T17:57:44

Which arch/os is that (to guess the gdbserver size differences)?  Is some
secondary storage really unavailable?  How much simple gdbserver would be
enough - for example do you need threading in that stage?


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

2012-05-21T17:36:57

I'm working on a system where the boot device has about a megabyte free space, on a good day.

paul

On May 21, 2012, at 12:14 PM, Jan Kratochvil wrote:

Re: Will therefore GDB utilize C++ or not?

Jan Kratochvil — 2012-05-21T16:14:56

Could you give specific still used device example where the current codebase
is OK while the triple gdbserver size is no longer OK?  All the discussions
are still very abstract.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

Pedro Alves — 2012-05-21T15:55:47



Thanks.  I appreciate them.  I didn't expect the code size to grow significantly,
as we had already seem similar comparisons done for gcc in the course of
the various C vs C++ discussions over there with similar results.
However, I'll note that such comparisons assume an unchanged C-style codebase,
and ignore the size increase you get when you actually start using C++
features, such as, throwing exceptions, or using iostream.  In my quick
experiment adding a cout << "foo" (-static-libstdc++ -flto -Os + strip) more
than triples the binary size.



That was for eCos, running on tiny embedded micro-controllers though.

I'm talking about things such as uclinux based routers vs big iron
GNU/Linux mainframes -- having only one codebase to maintain that
has to know ptrace intricasy, for example.

Re: Will therefore GDB utilize C++ or not?

Frank Ch. Eigler — 2012-05-20T12:15:39

Joel Brobecker <brobecker< at >adacore.com> writes:


Could y'all embrace a minimal gdbserver for cross-compilation bringup
purposes, instead of holding back relatively rich working platforms?
http://sourceware.org/rda/ et al., maybe connected tighter to the gdb
build system?

- FChE