From: Tom Tromey <tromey@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb@sourceware.org
Subject: Re: Will therefore GDB utilize C++ or not?
Date: Mon, 21 May 2012 18:08:00 -0000 [thread overview]
Message-ID: <87vcjpe9iy.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4FBA72B9.9010103@redhat.com> (Pedro Alves's message of "Mon, 21 May 2012 17:52:09 +0100")
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
next prev parent reply other threads:[~2012-05-21 18:08 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-30 16:14 Jan Kratochvil
2012-04-04 20:48 ` Tom Tromey
2012-04-04 21:55 ` Mark Kettenis
2012-04-05 3:31 ` Sergio Durigan Junior
2012-04-05 11:46 ` Phil Muldoon
2012-04-06 0:35 ` Will therefore GDB utilize C++? Not John Gilmore
2012-04-06 1:35 ` Russell Shaw
2012-04-06 13:16 ` Joel Brobecker
2012-04-06 14:43 ` Russell Shaw
2012-04-06 15:34 ` Michael Eager
2012-04-06 23:32 ` John Gilmore
2012-04-07 1:04 ` Robert Dewar
2012-04-07 1:52 ` Thomas Dineen
2012-04-07 16:54 ` Michael Eager
2012-04-09 23:59 ` Stan Shebs
2012-04-05 0:22 ` Will therefore GDB utilize C++ or not? asmwarrior
2012-04-09 18:41 ` Pedro Alves
2012-04-09 19:05 ` Jan Kratochvil
2012-04-09 19:49 ` Pedro Alves
2012-04-09 20:15 ` Paul Smith
2012-04-12 20:06 ` Daniel Jacobowitz
2012-04-12 21:28 ` Paul_Koning
2012-04-13 0:04 ` Doug Evans
2012-04-18 14:10 ` Pedro Alves
2012-04-18 20:27 ` Tom Tromey
2012-04-18 14:08 ` Pedro Alves
2012-04-21 17:24 ` Daniel Jacobowitz
2012-04-16 6:55 ` Jan Kratochvil
2012-04-18 14:11 ` Pedro Alves
2012-04-18 15:16 ` Jan Kratochvil
2012-04-18 15:28 ` Pedro Alves
2012-04-18 15:54 ` Jan Kratochvil
2012-04-18 16:01 ` Pedro Alves
2012-04-18 16:07 ` Joel Brobecker
2012-04-18 16:13 ` Jan Kratochvil
2012-04-18 16:23 ` Joel Brobecker
2012-04-18 16:31 ` Joel Sherrill
2012-04-18 16:50 ` Pedro Alves
2012-04-18 16:57 ` Joel Brobecker
2012-04-18 17:28 ` Joel Sherrill
2012-04-18 17:40 ` Paul_Koning
2012-04-18 20:37 ` Frank Ch. Eigler
2012-04-18 20:38 ` Paul_Koning
2012-04-18 20:36 ` Tom Tromey
2012-04-18 17:48 ` John Gilmore
2012-04-18 19:07 ` Tom Tromey
2012-04-18 23:10 ` John Gilmore
2012-05-18 18:36 ` Tom Tromey
2012-05-18 18:47 ` Paul_Koning
2012-05-18 19:36 ` Tom Tromey
2012-05-18 19:44 ` Paul_Koning
2012-05-18 20:07 ` Tom Tromey
2012-05-18 20:41 ` Aurelian Melinte
2012-05-18 18:51 ` Lazy CU expansion (Was: Will therefore GDB utilize C++ or not?) Tom Tromey
2012-04-18 20:34 ` Will therefore GDB utilize C++ or not? Tom Tromey
2012-04-18 19:18 ` Will C++ proponents spend 20 minutes to try what they're proposing? John Gilmore
2012-04-18 19:23 ` Jan Kratochvil
2012-04-18 20:40 ` Tom Tromey
2012-04-18 20:56 ` Mike Frysinger
2012-04-18 20:31 ` Will therefore GDB utilize C++ or not? Tom Tromey
2012-04-18 20:25 ` Tom Tromey
2012-05-21 18:11 ` Pedro Alves
2012-05-21 18:36 ` Jan Kratochvil
2012-11-21 20:18 ` Jan Kratochvil
2012-04-10 0:23 ` Yao Qi
2012-04-10 9:47 ` Yao Qi
2012-04-18 20:11 ` Tom Tromey
2012-04-18 20:31 ` Can it really be ok to map GPL'd code into any old process? John Gilmore
2012-04-18 20:36 ` Pedro Alves
2012-04-23 18:03 ` Will therefore GDB utilize C++ or not? Tom Tromey
2012-05-18 19:55 ` Tom Tromey
2012-05-18 21:56 ` Joel Brobecker
2012-05-19 2:17 ` Tom Tromey
2012-05-19 15:21 ` Daniel Jacobowitz
2012-05-19 21:36 ` Joel Brobecker
2012-05-20 12:16 ` Frank Ch. Eigler
2012-05-21 15:56 ` Pedro Alves
2012-05-21 16:15 ` Jan Kratochvil
2012-05-21 17:37 ` Paul_Koning
2012-05-21 17:58 ` Jan Kratochvil
2012-05-22 18:03 ` Paul_Koning
2012-05-21 18:08 ` Pedro Alves
2012-05-21 18:08 ` Tom Tromey [this message]
2012-05-21 18:10 ` Jan Kratochvil
2012-05-21 18:54 ` Matt Rice
2012-05-26 15:50 ` Jan Kratochvil
2012-06-02 7:01 ` Russell Shaw
2012-06-02 7:13 ` Jan Kratochvil
2012-06-02 10:47 ` Russell Shaw
2012-06-02 11:10 ` Jan Kratochvil
2012-06-02 11:15 ` Russell Shaw
2012-06-02 11:15 ` Jan Kratochvil
2012-11-22 18:46 ` Jan Kratochvil
2012-11-22 21:42 ` John Gilmore
2012-11-23 15:26 ` Jan Kratochvil
2012-11-27 1:29 ` Stan Shebs
2012-11-27 2:02 ` Paul_Koning
2012-11-27 2:59 ` Stan Shebs
2012-11-27 15:17 ` Paul_Koning
2012-11-27 21:14 ` Tom Tromey
2012-04-09 23:23 ` Stan Shebs
2012-04-18 14:22 ` Pedro Alves
2012-04-18 18:12 ` Stan Shebs
2012-04-18 18:32 ` Paul_Koning
2012-04-18 18:37 ` Pedro Alves
2012-04-19 8:43 ` Yao Qi
2012-12-04 14:17 ` Jan Kratochvil
2012-12-04 14:44 ` Mark Kettenis
2012-12-04 14:52 ` Jan Kratochvil
2012-12-06 20:39 ` Matt Rice
2012-12-07 12:57 ` Jan Kratochvil
2012-12-07 13:25 ` Yao Qi
2012-12-11 6:25 ` Matt Rice
2012-12-13 15:12 ` Jan Kratochvil
2012-12-14 11:03 ` Matt Rice
2012-12-14 12:16 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vcjpe9iy.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).