* Formatting of function pointer value @ 2005-07-08 8:02 Vladimir Prus 2005-07-08 8:51 ` Vladimir Prus 2005-07-08 13:58 ` Daniel Jacobowitz 0 siblings, 2 replies; 19+ messages in thread From: Vladimir Prus @ 2005-07-08 8:02 UTC (permalink / raw) To: gdb Hello, consider the following snippet: B* p2 = (B*)0x12345678; int (*p3)(int) = (fp)0x000000AE; the value of p2 is printed like this: (gdb)info local .... p2 = (B *) 0xb8000540 the value of *p3 is printed like this: (gdb) print *p3 $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> I have a couple of questions: 1. Why in both cases the type of value is printed? There's already 'whatis' command. I've checked that code and it's printed unconditionally. As the result, a GDB frontend must strip the type. 2. Why the type is enclosed in parenthesis in the first case, and in braces in the second case? This entails additonal problems for GUI frontend, for example, at the moment KDevelop thinks that the opening brace in the second case starts a composite. - Volodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-08 8:02 Formatting of function pointer value Vladimir Prus @ 2005-07-08 8:51 ` Vladimir Prus 2005-07-08 13:59 ` Daniel Jacobowitz 2005-07-08 13:58 ` Daniel Jacobowitz 1 sibling, 1 reply; 19+ messages in thread From: Vladimir Prus @ 2005-07-08 8:51 UTC (permalink / raw) To: gdb Vladimir Prus wrote: > the value of *p3 is printed like this: > > (gdb) print *p3 > $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> Even more strange is this: (gdb) print p3 $2 = (int (*)(int)) 0xb7ee6e9c <__DTOR_END__+4> (gdb) print *p3 $3 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> Why does formatting of the type different in the second case, and uses braces instead of parenthesis? - VOlodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-08 8:51 ` Vladimir Prus @ 2005-07-08 13:59 ` Daniel Jacobowitz 2005-07-11 5:40 ` Vladimir Prus 0 siblings, 1 reply; 19+ messages in thread From: Daniel Jacobowitz @ 2005-07-08 13:59 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb On Fri, Jul 08, 2005 at 12:50:48PM +0400, Vladimir Prus wrote: > Vladimir Prus wrote: > > > > the value of *p3 is printed like this: > > > > (gdb) print *p3 > > $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> > > Even more strange is this: > > (gdb) print p3 > $2 = (int (*)(int)) 0xb7ee6e9c <__DTOR_END__+4> > (gdb) print *p3 > $3 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> > > Why does formatting of the type different in the second case, and uses > braces instead of parenthesis? One is a pointer to function, the other is a function. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-08 13:59 ` Daniel Jacobowitz @ 2005-07-11 5:40 ` Vladimir Prus 2005-07-11 7:11 ` Vladimir Prus 2005-07-11 8:35 ` Andreas Schwab 0 siblings, 2 replies; 19+ messages in thread From: Vladimir Prus @ 2005-07-11 5:40 UTC (permalink / raw) To: gdb Daniel Jacobowitz wrote: > On Fri, Jul 08, 2005 at 12:50:48PM +0400, Vladimir Prus wrote: >> Vladimir Prus wrote: >> >> >> > the value of *p3 is printed like this: >> > >> > (gdb) print *p3 >> > $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> >> >> Even more strange is this: >> >> (gdb) print p3 >> $2 = (int (*)(int)) 0xb7ee6e9c <__DTOR_END__+4> >> (gdb) print *p3 >> $3 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> >> >> Why does formatting of the type different in the second case, and uses >> braces instead of parenthesis? > > One is a pointer to function, the other is a function. I'm sorry, I don't understand this. Is human user supposed to know that '{' starts a function? What harm will it make if parenthesis are used in both cases? - Volodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 5:40 ` Vladimir Prus @ 2005-07-11 7:11 ` Vladimir Prus 2005-07-11 8:35 ` Andreas Schwab 1 sibling, 0 replies; 19+ messages in thread From: Vladimir Prus @ 2005-07-11 7:11 UTC (permalink / raw) To: gdb Vladimir Prus wrote: > Daniel Jacobowitz wrote: > >> On Fri, Jul 08, 2005 at 12:50:48PM +0400, Vladimir Prus wrote: >>> Vladimir Prus wrote: >>> >>> >>> > the value of *p3 is printed like this: >>> > >>> > (gdb) print *p3 >>> > $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> >>> >>> Even more strange is this: >>> >>> (gdb) print p3 >>> $2 = (int (*)(int)) 0xb7ee6e9c <__DTOR_END__+4> >>> (gdb) print *p3 >>> $3 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> >>> >>> Why does formatting of the type different in the second case, and uses >>> braces instead of parenthesis? >> >> One is a pointer to function, the other is a function. > > I'm sorry, I don't understand this. Is human user supposed to know that > '{' starts a function? What harm will it make if parenthesis are used in > both cases? BTW, the code in question says: /* FIXME, we should consider, at least for ANSI C language, eliminating the distinction made between FUNCs and POINTERs to FUNCs. */ fprintf_filtered (stream, "{"); type_print (type, "", stream, -1); fprintf_filtered (stream, "} "); Is "FIXME" still relevant? - Volodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 5:40 ` Vladimir Prus 2005-07-11 7:11 ` Vladimir Prus @ 2005-07-11 8:35 ` Andreas Schwab 2005-07-11 13:03 ` Daniel Jacobowitz 1 sibling, 1 reply; 19+ messages in thread From: Andreas Schwab @ 2005-07-11 8:35 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb Vladimir Prus <ghost@cs.msu.su> writes: > I'm sorry, I don't understand this. Is human user supposed to know that '{' > starts a function? What harm will it make if parenthesis are used in both > cases? `{TYPE} ADDR' is a special syntax for expressions in gdb and is actually a shorthand for `*(TYPE *) ADDR'. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 8:35 ` Andreas Schwab @ 2005-07-11 13:03 ` Daniel Jacobowitz 0 siblings, 0 replies; 19+ messages in thread From: Daniel Jacobowitz @ 2005-07-11 13:03 UTC (permalink / raw) To: Andreas Schwab; +Cc: Vladimir Prus, gdb On Mon, Jul 11, 2005 at 10:34:55AM +0200, Andreas Schwab wrote: > Vladimir Prus <ghost@cs.msu.su> writes: > > > I'm sorry, I don't understand this. Is human user supposed to know that '{' > > starts a function? What harm will it make if parenthesis are used in both > > cases? > > `{TYPE} ADDR' is a special syntax for expressions in gdb and is actually a > shorthand for `*(TYPE *) ADDR'. Woah... and yes, it's in the manual. Thanks, Andreas; I've never seen that syntax before! -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-08 8:02 Formatting of function pointer value Vladimir Prus 2005-07-08 8:51 ` Vladimir Prus @ 2005-07-08 13:58 ` Daniel Jacobowitz 2005-07-11 5:38 ` Vladimir Prus 1 sibling, 1 reply; 19+ messages in thread From: Daniel Jacobowitz @ 2005-07-08 13:58 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb On Fri, Jul 08, 2005 at 12:00:44PM +0400, Vladimir Prus wrote: > > Hello, > consider the following snippet: > > B* p2 = (B*)0x12345678; > int (*p3)(int) = (fp)0x000000AE; > > the value of p2 is printed like this: > > (gdb)info local > .... > p2 = (B *) 0xb8000540 > > > the value of *p3 is printed like this: > > (gdb) print *p3 > $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> > > I have a couple of questions: > > 1. Why in both cases the type of value is printed? There's already 'whatis' > command. I've checked that code and it's printed unconditionally. As the > result, a GDB frontend must strip the type. It is a feature, not a bug. Why is your frontend using the command-line interface? DON'T do that! Use MI nowadays, please please please. The type is included because "print p2; $1 = 0x12345678" is very uninformative; that's how we print integers, not pointers. > 2. Why the type is enclosed in parenthesis in the first case, and in braces > in the second case? This entails additonal problems for GUI frontend, for > example, at the moment KDevelop thinks that the opening brace in the second > case starts a composite. Code addresses are treated specially. Same reason why you get a symbol name, I expect... -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-08 13:58 ` Daniel Jacobowitz @ 2005-07-11 5:38 ` Vladimir Prus 2005-07-11 7:06 ` Nick Roberts 0 siblings, 1 reply; 19+ messages in thread From: Vladimir Prus @ 2005-07-11 5:38 UTC (permalink / raw) To: gdb Daniel Jacobowitz wrote: > On Fri, Jul 08, 2005 at 12:00:44PM +0400, Vladimir Prus wrote: >> >> Hello, >> consider the following snippet: >> >> B* p2 = (B*)0x12345678; >> int (*p3)(int) = (fp)0x000000AE; >> >> the value of p2 is printed like this: >> >> (gdb)info local >> .... >> p2 = (B *) 0xb8000540 >> >> >> the value of *p3 is printed like this: >> >> (gdb) print *p3 >> $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4> >> >> I have a couple of questions: >> >> 1. Why in both cases the type of value is printed? There's already >> 'whatis' command. I've checked that code and it's printed >> unconditionally. As the result, a GDB frontend must strip the type. > > It is a feature, not a bug. Why is your frontend using the > command-line interface? Well, the debugger part in KDevelop was not written by me, so I don't know why command-line interface, and not MI is used. > DON'T do that! Use MI nowadays, please please > please. I'm sorry, but section 24 of gdb manual does not say why MI is better. Can you give the reasons? > The type is included because "print p2; $1 = 0x12345678" is very > uninformative; that's how we print integers, not pointers. I suppose that if I do "print p2" I have some idea what type of 'p2' is; I don't print program variables at random. - Volodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 5:38 ` Vladimir Prus @ 2005-07-11 7:06 ` Nick Roberts 2005-07-11 7:21 ` Vladimir Prus 0 siblings, 1 reply; 19+ messages in thread From: Nick Roberts @ 2005-07-11 7:06 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb > > It is a feature, not a bug. Why is your frontend using the > > command-line interface? > > Well, the debugger part in KDevelop was not written by me, so I don't know > why command-line interface, and not MI is used. > > > DON'T do that! Use MI nowadays, please please > > please. > > I'm sorry, but section 24 of gdb manual does not say why MI is better. Can > you give the reasons? CLI output is intended for the user. It can change with a new release, and on the state of execution in ways which are not easy to anticipate without reading the source code. Provided that it still makes sense, that is not a problem to the user but it can be to a frontend, if it is trying to parse the output in a very precise manner. MI has a more formal syntax and so is not as variable. Once it is fully developed, its output should be stable and if it does change, some backward compatibility will probably be maintained. Nick ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 7:06 ` Nick Roberts @ 2005-07-11 7:21 ` Vladimir Prus 2005-07-11 7:42 ` Vladimir Prus 2005-07-11 8:08 ` Nick Roberts 0 siblings, 2 replies; 19+ messages in thread From: Vladimir Prus @ 2005-07-11 7:21 UTC (permalink / raw) To: gdb Nick Roberts wrote: > > > It is a feature, not a bug. Why is your frontend using the > > > command-line interface? > > > > Well, the debugger part in KDevelop was not written by me, so I don't > > know why command-line interface, and not MI is used. > > > > > DON'T do that! Use MI nowadays, please please > > > please. > > > > I'm sorry, but section 24 of gdb manual does not say why MI is better. > > Can you give the reasons? > > CLI output is intended for the user. It can change with a new release, > and on the state of execution in ways which are not easy to anticipate > without > reading the source code. Provided that it still makes sense, that is not > a problem to the user but it can be to a frontend, if it is trying to > parse the > output in a very precise manner. MI has a more formal syntax and so is > not as > variable. Once it is fully developed, So it's not stable yet? > its output should be stable and if > it does change, some backward compatibility will probably be maintained. Ok, the the only advantage of MI is stable output format. Can you tell me how it's achieved? For example, looking at the code that prints function values (what worries me in the first place): fprintf_filtered (stream, "{"); type_print (type, "", stream, -1); fprintf_filtered (stream, "} "); As I right in assuming that exactly the same output will be produced for MI mode and for CLI mode? If so, then how MI can be more stable than CLI, if the output is the same? - Volodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 7:21 ` Vladimir Prus @ 2005-07-11 7:42 ` Vladimir Prus 2005-07-11 13:08 ` Daniel Jacobowitz 2005-07-11 8:08 ` Nick Roberts 1 sibling, 1 reply; 19+ messages in thread From: Vladimir Prus @ 2005-07-11 7:42 UTC (permalink / raw) To: gdb Vladimir Prus wrote: > Ok, the the only advantage of MI is stable output format. Can you tell me > how it's achieved? For example, looking at the code that prints function > values (what worries me in the first place): > > fprintf_filtered (stream, "{"); > type_print (type, "", stream, -1); > fprintf_filtered (stream, "} "); > > As I right in assuming that exactly the same output will be produced for > MI mode and for CLI mode? If so, then how MI can be more stable than CLI, > if the output is the same? To clarify more, here's what I get with MI: -data-evaluate-expression *p3 ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>" (gdb) -var-create VP3 0 *p3 ^done,name="VP3",numchild="0",type="int (int)" (gdb) -var-evaluate-expression VP3 ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>" The type enclosed in {} is still there. - Volodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 7:42 ` Vladimir Prus @ 2005-07-11 13:08 ` Daniel Jacobowitz 2005-07-11 13:21 ` Vladimir Prus 0 siblings, 1 reply; 19+ messages in thread From: Daniel Jacobowitz @ 2005-07-11 13:08 UTC (permalink / raw) To: gdb On Mon, Jul 11, 2005 at 11:40:21AM +0400, Vladimir Prus wrote: > Vladimir Prus wrote: > > > Ok, the the only advantage of MI is stable output format. Can you tell me > > how it's achieved? For example, looking at the code that prints function > > values (what worries me in the first place): > > > > fprintf_filtered (stream, "{"); > > type_print (type, "", stream, -1); > > fprintf_filtered (stream, "} "); > > > > As I right in assuming that exactly the same output will be produced for > > MI mode and for CLI mode? If so, then how MI can be more stable than CLI, > > if the output is the same? > > To clarify more, here's what I get with MI: > > -data-evaluate-expression *p3 > ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>" > (gdb) > -var-create VP3 0 *p3 > ^done,name="VP3",numchild="0",type="int (int)" > (gdb) > -var-evaluate-expression VP3 > ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>" > > The type enclosed in {} is still there. The intention is that this is a user-readable value, to be displayed. There's limited facility for computing values with machine-readable results, probably because there has been limited need for it to date. You can get some information more precisely - for instance the type. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 13:08 ` Daniel Jacobowitz @ 2005-07-11 13:21 ` Vladimir Prus 2005-07-11 13:27 ` Daniel Jacobowitz 0 siblings, 1 reply; 19+ messages in thread From: Vladimir Prus @ 2005-07-11 13:21 UTC (permalink / raw) To: gdb Daniel Jacobowitz wrote: >> To clarify more, here's what I get with MI: >> >> -data-evaluate-expression *p3 >> ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>" >> (gdb) >> -var-create VP3 0 *p3 >> ^done,name="VP3",numchild="0",type="int (int)" >> (gdb) >> -var-evaluate-expression VP3 >> ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>" >> >> The type enclosed in {} is still there. > > The intention is that this is a user-readable value, to be displayed. Hmm.. since MI is for gdb frontends, this just imposes work for frontend. It frontend wants to display the type, it can get this information easily with extra MI command, while stripping '{}' is somewhat hacky. Especially because {} is also used to delimit arrays. > There's limited facility for computing values with machine-readable > results, probably because there has been limited need for it to date. So, 1. It's not possible to avoid those {} in the current code, using MI or CLI. 2. It's not likely that this will change Right? If so, then I'll just drop the ball, and use a hacky {}-stripping code in kdevelop. - Volodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 13:21 ` Vladimir Prus @ 2005-07-11 13:27 ` Daniel Jacobowitz 2005-07-14 8:10 ` Vladimir Prus 0 siblings, 1 reply; 19+ messages in thread From: Daniel Jacobowitz @ 2005-07-11 13:27 UTC (permalink / raw) To: gdb On Mon, Jul 11, 2005 at 05:12:47PM +0400, Vladimir Prus wrote: > > There's limited facility for computing values with machine-readable > > results, probably because there has been limited need for it to date. > > So, > 1. It's not possible to avoid those {} in the current code, using MI or CLI. > 2. It's not likely that this will change > Right? That's the opposite of what I said. If there's a need for printing the values in some "raw" form, then a new MI command can be added to do so. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 13:27 ` Daniel Jacobowitz @ 2005-07-14 8:10 ` Vladimir Prus 0 siblings, 0 replies; 19+ messages in thread From: Vladimir Prus @ 2005-07-14 8:10 UTC (permalink / raw) To: gdb Daniel Jacobowitz wrote: > On Mon, Jul 11, 2005 at 05:12:47PM +0400, Vladimir Prus wrote: >> > There's limited facility for computing values with machine-readable >> > results, probably because there has been limited need for it to date. >> >> So, >> 1. It's not possible to avoid those {} in the current code, using MI or >> CLI. 2. It's not likely that this will change >> Right? > > That's the opposite of what I said. If there's a need for printing the > values in some "raw" form, then a new MI command can be added to do so. But why a new command? MI is for frontends and they don't need any decoration of the value. Why not eliminate {} in MI mode? - Volodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 7:21 ` Vladimir Prus 2005-07-11 7:42 ` Vladimir Prus @ 2005-07-11 8:08 ` Nick Roberts 2005-07-11 9:05 ` Vladimir Prus 1 sibling, 1 reply; 19+ messages in thread From: Nick Roberts @ 2005-07-11 8:08 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb > > CLI output is intended for the user. It can change with a new release, > > and on the state of execution in ways which are not easy to anticipate > > without reading the source code. Provided that it still makes sense, > > that is not a problem to the user but it can be to a frontend, if it is > > trying to parse the output in a very precise manner. MI has a more > > formal syntax and so is not as variable. Once it is fully developed, > > So it's not stable yet? The manual says: Note that GDB/MI is still under construction, so some of the features described below are incomplete and subject to change. > > its output should be stable and if > > it does change, some backward compatibility will probably be maintained. > > Ok, the the only advantage of MI is stable output format. I've not said that. It also uses variable objects, it aims to be asynchronous... > Can you tell me how it's achieved? As I've already said, it has a more formal syntax. > For example, looking at the code that prints function values (what worries > me in the first place): > > fprintf_filtered (stream, "{"); > type_print (type, "", stream, -1); > fprintf_filtered (stream, "} "); I don't understand the point of the example. > As I right in assuming that exactly the same output will be produced for MI > mode and for CLI mode? No, you're wrong to assume that. That should be clear from the examples in the manual. Nick > If so, then how MI can be more stable than CLI, if the output is the same? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 8:08 ` Nick Roberts @ 2005-07-11 9:05 ` Vladimir Prus 2005-07-11 9:53 ` Nick Roberts 0 siblings, 1 reply; 19+ messages in thread From: Vladimir Prus @ 2005-07-11 9:05 UTC (permalink / raw) To: gdb Nick Roberts wrote: > > > its output should be stable and if > > > it does change, some backward compatibility will probably be > > > maintained. > > > > Ok, the the only advantage of MI is stable output format. > > I've not said that. It also uses variable objects, it aims to be > asynchronous... Could you give more details? Basically, Daniel suggested that I use MI instead of CLI. I've asked about the reasons why I should, and if possible, I'd like to see all reasons, with a easy to understand descriptions. For example, the term "variable objects" says nothing to me, and it's description: For the implementation of a variable debugger window (locals, watched expressions, etc.), we are proposing the adaptation of the existing code used by `Insight'. does not sched might light either. >> Can you tell me how it's achieved? > > As I've already said, it has a more formal syntax. > > > For example, looking at the code that prints function values (what > > worries me in the first place): > > > > fprintf_filtered (stream, "{"); > > type_print (type, "", stream, -1); > > fprintf_filtered (stream, "} "); > > I don't understand the point of the example. The point of the example is that this code seem to be executed both in MI and CLI modes. So, if '{' is changed to '(', it will equally affect MI and CLI, which makes me wonder why MI is more stable that CLI. As you can see from my other post, the formatting of value is indeed the same for MI and CLI. - Volodya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Formatting of function pointer value 2005-07-11 9:05 ` Vladimir Prus @ 2005-07-11 9:53 ` Nick Roberts 0 siblings, 0 replies; 19+ messages in thread From: Nick Roberts @ 2005-07-11 9:53 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb > > > Ok, the the only advantage of MI is stable output format. > > > > I've not said that. It also uses variable objects, it aims to be > > asynchronous... > > Could you give more details? Basically, Daniel suggested that I use MI > instead of CLI. I think thats sound advice. If you use CLI for KDevelop (?) and then GDB developers change the CLI output, it will break things for you and you'll have wasted a lot of effort. > I've asked about the reasons why I should, and if possible, I'd like to see > all reasons, with a easy to understand descriptions. I don't think you'll get that. GDB is a voluntary project. You just have to work with what's available (or pay someone). > For example, the term "variable objects" says nothing to me, and it's > description: > > For the implementation of a variable debugger window (locals, watched > expressions, etc.), we are proposing the adaptation of the existing code > used by `Insight'. > > does not sched might light either. I've learnt what I know about variable objects from using Insight, reading the manual and looking at the source code. I still don't understand the asynchronous operation which only works under limited conditions. ... > > > For example, looking at the code that prints function values (what > > > worries me in the first place): > > > > > > fprintf_filtered (stream, "{"); > > > type_print (type, "", stream, -1); > > > fprintf_filtered (stream, "} "); > > > > I don't understand the point of the example. > > The point of the example is that this code seem to be executed both in MI > and CLI modes. So, if '{' is changed to '(', it will equally affect MI and > CLI, which makes me wonder why MI is more stable that CLI. If you are going to generalise the whole of MI and CLI from this one very small example, then I can see that it would make you wonder why MI is more stable that CLI > As you can see from my other post, the formatting of value is indeed the > same for MI and CLI. Yes, but you can easily parse the MI output and replace '{' with whatever you want. Nick ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2005-07-14 8:10 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-08 8:02 Formatting of function pointer value Vladimir Prus 2005-07-08 8:51 ` Vladimir Prus 2005-07-08 13:59 ` Daniel Jacobowitz 2005-07-11 5:40 ` Vladimir Prus 2005-07-11 7:11 ` Vladimir Prus 2005-07-11 8:35 ` Andreas Schwab 2005-07-11 13:03 ` Daniel Jacobowitz 2005-07-08 13:58 ` Daniel Jacobowitz 2005-07-11 5:38 ` Vladimir Prus 2005-07-11 7:06 ` Nick Roberts 2005-07-11 7:21 ` Vladimir Prus 2005-07-11 7:42 ` Vladimir Prus 2005-07-11 13:08 ` Daniel Jacobowitz 2005-07-11 13:21 ` Vladimir Prus 2005-07-11 13:27 ` Daniel Jacobowitz 2005-07-14 8:10 ` Vladimir Prus 2005-07-11 8:08 ` Nick Roberts 2005-07-11 9:05 ` Vladimir Prus 2005-07-11 9:53 ` Nick Roberts
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).