On Tue, Nov 27, 2012 at 8:54 AM, Tom Tromey wrote:
>> "Gaby" == Gabriel Dos Reis writes:
>
> Richard> Just to add another case which seems to be not covered in the thread.
> Richard> When dumping from inside a gdb session in many cases I cut&paste
> Richard> addresses literally. For overload
On Tue, Nov 27, 2012 at 10:23 AM, Richard Biener
wrote:
> me too, just when you do debug_tree ($1) you then don't have $nn for
> all of the trees referenced from the output ;)
True that :)
On Tue, Nov 27, 2012 at 4:06 PM, Diego Novillo wrote:
> On Sun, Nov 25, 2012 at 8:45 AM, Richard Biener
> wrote:
>
>> Just to add another case which seems to be not covered in the thread.
>> When dumping from inside a gdb session in many cases I cut&paste
>> addresses literally. For overloading
On Sun, Nov 25, 2012 at 8:45 AM, Richard Biener
wrote:
> Just to add another case which seems to be not covered in the thread.
> When dumping from inside a gdb session in many cases I cut&paste
> addresses literally. For overloading to work I'd need to write casts
> in front of the inferior call
> "Gaby" == Gabriel Dos Reis writes:
Richard> Just to add another case which seems to be not covered in the thread.
Richard> When dumping from inside a gdb session in many cases I cut&paste
Richard> addresses literally. For overloading to work I'd need to write casts
Richard> in front of the
On Sun, Nov 25, 2012 at 7:45 AM, Richard Biener
wrote:
> Just to add another case which seems to be not covered in the thread.
> When dumping from inside a gdb session in many cases I cut&paste
> addresses literally. For overloading to work I'd need to write casts
> in front of the inferior call
On Thu, Nov 15, 2012 at 2:12 AM, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
> It is sometimes hard to remember which printing function is used
> for debugging a type, or even which type you have.
>
> We propose to rely on overloading to unify the
Thanks for all the comments.
I have incorporated all the feedback (I hope). We will start
implementing this in the cxx-conversion branch.
I've created a new wiki page with the debugging proposal:
http://gcc.gnu.org/wiki/cxx-conversion/debugging-dumps
It is also indexed from the general improvem
On Wed, Nov 21, 2012 at 9:02 AM, Ian Lance Taylor wrote:
> On Wed, Nov 21, 2012 at 3:18 AM, Gabriel Dos Reis
> wrote:
>> On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl wrote:
>>
>>> And, as a side note, highly formatted output generally is not
>>> much better than printf. For any text that nee
On Wed, Nov 21, 2012 at 3:18 AM, Gabriel Dos Reis
wrote:
> On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl wrote:
>
>> And, as a side note, highly formatted output generally is not
>> much better than printf. For any text that needs to be localized,
>> I recommend that we stick with what we have
I forgot to add this important information: you don't get the nifty
counters if you don't include . Specifically.
That means including or does not
introduce any nifty counter. Including , which
allows you to perform in-memory formatted IO, does not
introduce any nifty counter. Said, differently
On 11/21/2012 03:25 PM, Gabriel Dos Reis wrote:
On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser wrote:
Is it correct to state that every translation unit that includes iostream
will include the iostream static constructors?
C++ requires the definitions of globals such as std::cin, std::cout,
On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser wrote:
> Is it correct to state that every translation unit that includes iostream
> will include the iostream static constructors?
C++ requires the definitions of globals such as std::cin, std::cout,
and std::cerr
that must be contructed (by any m
On 11/21/2012 02:33 PM, Gabriel Dos Reis wrote:
On Wed, Nov 21, 2012 at 7:07 AM, Tobias Grosser wrote:
On 11/20/2012 08:32 PM, Basile Starynkevitch wrote:
On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
[]
All of these functions come in two forms.
function (FILE
On Wed, Nov 21, 2012 at 7:07 AM, Tobias Grosser wrote:
> On 11/20/2012 08:32 PM, Basile Starynkevitch wrote:
>>
>> On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
>> []
>
> All of these functions come in two forms.
>
> function (FILE *, item_to_dump, forma
On 11/20/2012 08:32 PM, Basile Starynkevitch wrote:
On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
[]
All of these functions come in two forms.
function (FILE *, item_to_dump, formatting)
function (item_to_dump, formatting)
Since we have switched to C++, it wo
Hi,
On Tue, 20 Nov 2012, Lawrence Crowl wrote:
> On 11/19/12, Diego Novillo wrote:
> > On Nov 19, 2012 Michael Matz wrote:
> > > So, yes, the larger layouting should be determined by name of the
> > > dump function. A flag argument might look nice from an interface
> > > design perspective, bu
On Wed, Nov 21, 2012 at 5:37 AM, Theodore Papadopoulo
wrote:
> On 11/21/2012 02:01 AM, Xinliang David Li wrote:
>>
>> Right -- gdb does not know the complete type of std::cout and
>> std::cerr -- try the following program with -g and invoke print, or <<
>> in the debugger -- see what you will get:
On 11/21/2012 02:01 AM, Xinliang David Li wrote:
Right -- gdb does not know the complete type of std::cout and
std::cerr -- try the following program with -g and invoke print, or <<
in the debugger -- see what you will get:
But that also suggest that the debugging experience needs for some
imp
On Tue, Nov 20, 2012 at 7:01 PM, Xinliang David Li wrote:
> Right -- gdb does not know the complete type of std::cout and
> std::cerr -- try the following program with -g and invoke print, or <<
> in the debugger -- see what you will get:
Is this because the hack we (libstdc++ folks) used to defi
On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl wrote:
> And, as a side note, highly formatted output generally is not
> much better than printf. For any text that needs to be localized,
> I recommend that we stick with what we have.
I agree with Lawrence that for texts that need localization,
Right -- gdb does not know the complete type of std::cout and
std::cerr -- try the following program with -g and invoke print, or <<
in the debugger -- see what you will get:
#include
using namespace std;
class A {
public:
int i;
};
__attribute__((noinline)) void print (ostream& os, const A& a)
On 11/20/12, Xinliang David Li wrote:
> one minus -- less gdb friendly.
Do you mean that gdb does not handle the stream expressions
or something else?
>
> David
>
> On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl wrote:
>> On 11/20/12, Diego Novillo wrote:
>>> On Nov 20, 2012 Basile Starynkevi
one minus -- less gdb friendly.
David
On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl wrote:
> On 11/20/12, Diego Novillo wrote:
>> On Nov 20, 2012 Basile Starynkevitch wrote:
>> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
>> > > function (FILE *, item_to_dump, formatting
On 11/20/12, Diego Novillo wrote:
> On Nov 20, 2012 Basile Starynkevitch wrote:
> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
> > > function (FILE *, item_to_dump, formatting)
> > > function (item_to_dump, formatting)
> >
> > Since we have switched to C++, it would be really
On Tue, Nov 20, 2012 at 2:32 PM, Basile Starynkevitch
wrote:
> On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
> []
>> >> All of these functions come in two forms.
>> >>
>> >> function (FILE *, item_to_dump, formatting)
>> >> function (item_to_dump, formatting)
>
> Si
On Tue, Nov 20, 2012 at 2:34 PM, Xinliang David Li wrote:
> class bitmap {
>public:
> void print_me (print_flags flags = print_pretty, FILE *stream = stderr);
> ...
> };
This is fine and all, but most of our objects are pointers and many
times we are dealing with NULL pointers. W
On Tue, Nov 20, 2012 at 12:03 PM, Andrew MacLeod wrote:
> On 11/14/2012 08:12 PM, Lawrence Crowl wrote:
>>
>> Diego and I seek your comments on the following (loose) proposal.
>>
>>
>> We propose to provide several function overload sets, as below.
>>
>>
>> dump_pretty
>>
>> This function ove
On Tue, Nov 20, 2012 at 11:19:41AM -0800, Lawrence Crowl wrote:
> On 11/19/12, Diego Novillo wrote:
> > On Nov 19, 2012 Michael Matz wrote:
> > > So, yes, the larger layouting should be determined by name of the
> > > dump function. A flag argument might look nice from an interface
> > > design
This can be simplified further -- there should be one print method for
every class/struct entity as a member method
enum print_flags
{
print_pretty = 0x1,
print_decl_only = 0x2,
print_raw = 0x4,
..
};
class bitmap {
public:
void print_me (print_flags flags = print_pretty, FI
On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
[]
> >> All of these functions come in two forms.
> >>
> >> function (FILE *, item_to_dump, formatting)
> >> function (item_to_dump, formatting)
Since we have switched to C++, it would be really nice to have dump functio
On 11/20/12, Andrew MacLeod wrote:
> On 11/14/2012 08:12 PM, Lawrence Crowl wrote:
>> Diego and I seek your comments on the following (loose) proposal.
>>
>>
>> We propose to provide several function overload sets, as below.
>>
>>
>> dump_pretty
>>
>> This function overload set provides the b
On 11/19/12, Diego Novillo wrote:
> On Nov 19, 2012 Michael Matz wrote:
> > So, yes, the larger layouting should be determined by name of the
> > dump function. A flag argument might look nice from an interface
> > design perspective, but it's harder to use in the debugger.
>
> As long as all th
On 11/14/2012 08:12 PM, Lawrence Crowl wrote:
Diego and I seek your comments on the following (loose) proposal.
We propose to provide several function overload sets, as below.
dump_pretty
This function overload set provides the bulk of the printing.
They will use the existing prett
On Mon, Nov 19, 2012 at 10:11 AM, Michael Matz wrote:
> So, yes, the larger layouting should be determined by name of the dump
> function. A flag argument might look nice from an interface design
> perspective, but it's harder to use in the debugger.
As long as all these different objects share
Hi,
On Mon, 19 Nov 2012, Martin Jambor wrote:
> Well, this is what I was actually afraid of. If things like generic
> or tree dump of a tree value is selected by new TDF_ flags, then you
> are in danger of just replacing current mess in function names by a
> mess of constants. I'd much rather h
On Mon, Nov 19, 2012 at 5:18 AM, Martin Jambor wrote:
> Hi,
>
> On Fri, Nov 16, 2012 at 08:08:52AM -0500, Diego Novillo wrote:
>> On Fri, Nov 16, 2012 at 4:38 AM, Martin Jambor wrote:
>>
>> > So you do not plan to replace/rename at least some of them? This
>> > seems like unnecessary and confusi
Hi,
On Fri, Nov 16, 2012 at 08:08:52AM -0500, Diego Novillo wrote:
> On Fri, Nov 16, 2012 at 4:38 AM, Martin Jambor wrote:
>
> > So you do not plan to replace/rename at least some of them? This
> > seems like unnecessary and confusing layering just to avoid the work
> > to do the right thing.
>
On Wed, Nov 14, 2012 at 8:48 PM, Andrew Pinski wrote:
> Here is my proposal though I don't have time to work on it. Make some
> python scripts which do the basic function of the debug_* functions.
No. Debug traces and -fdump-* support.
Python pretty printers for gdb would be great, of course.
On Fri, Nov 16, 2012 at 4:38 AM, Martin Jambor wrote:
> So you do not plan to replace/rename at least some of them? This
> seems like unnecessary and confusing layering just to avoid the work
> to do the right thing.
No, we plan to replace all the existing dumping routines. We are just
not pla
Hi,
On Wed, Nov 14, 2012 at 05:12:15PM -0800, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
> It is sometimes hard to remember which printing function is used
> for debugging a type, or even which type you have.
Yeah, from time to time a still nee
On 11/14/12, Andrew Pinski wrote:
> On Nov 14, 2012, Lawrence Crowl wrote:
>> Diego and I seek your comments on the following (loose) proposal.
>>
>>
>> It is sometimes hard to remember which printing function is used
>> for debugging a type, or even which type you have.
>>
>> We propose to rely
On Wed, Nov 14, 2012 at 5:12 PM, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
> It is sometimes hard to remember which printing function is used
> for debugging a type, or even which type you have.
>
> We propose to rely on overloading to unify the
Diego and I seek your comments on the following (loose) proposal.
It is sometimes hard to remember which printing function is used
for debugging a type, or even which type you have.
We propose to rely on overloading to unify the interface to a small
set of function names. Every major data type
44 matches
Mail list logo
