* RFC: DW_TAG_try_block
@ 2003-05-26 19:46 H. J. Lu
2003-05-26 19:59 ` Daniel Jacobowitz
2003-05-27 14:46 ` Elena Zannoni
0 siblings, 2 replies; 10+ messages in thread
From: H. J. Lu @ 2003-05-26 19:46 UTC (permalink / raw)
To: GDB
Intel C++ compiler generates DW_TAG_try_block for
try
{
...
}
Gdb can't print any local variables declared inside the try block. This
patch seems to work for us. Is that correct?
H.J.
---
2003-05-26 H.J. Lu <hongjiu.lu@intel.com>
* dwarf2read.c (process_die): Handle DW_TAG_try_block.
--- gdb/dwarf2read.c.try 2003-05-26 12:23:22.000000000 -0700
+++ gdb/dwarf2read.c 2003-05-26 12:37:08.000000000 -0700
@@ -1768,6 +1768,7 @@ process_die (struct die_info *die, struc
of a function and make GDB `next' properly over inlined functions. */
break;
case DW_TAG_lexical_block:
+ case DW_TAG_try_block:
read_lexical_block_scope (die, objfile, cu_header);
break;
case DW_TAG_class_type:
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: DW_TAG_try_block
2003-05-26 19:46 RFC: DW_TAG_try_block H. J. Lu
@ 2003-05-26 19:59 ` Daniel Jacobowitz
2003-05-26 20:16 ` H. J. Lu
2003-05-27 14:46 ` Elena Zannoni
1 sibling, 1 reply; 10+ messages in thread
From: Daniel Jacobowitz @ 2003-05-26 19:59 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
On Mon, May 26, 2003 at 12:44:43PM -0700, H. J. Lu wrote:
> Intel C++ compiler generates DW_TAG_try_block for
>
> try
> {
> ...
> }
>
> Gdb can't print any local variables declared inside the try block. This
> patch seems to work for us. Is that correct?
I believe that this is correct, and that (at least for now) the same
thing should be done for DW_TAG_catch_block. There's a PR for this
issue.
[But wait for a DWARF maintainer to comment, please.]
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: DW_TAG_try_block
2003-05-26 19:59 ` Daniel Jacobowitz
@ 2003-05-26 20:16 ` H. J. Lu
0 siblings, 0 replies; 10+ messages in thread
From: H. J. Lu @ 2003-05-26 20:16 UTC (permalink / raw)
To: GDB
On Mon, May 26, 2003 at 03:56:46PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 26, 2003 at 12:44:43PM -0700, H. J. Lu wrote:
> > Intel C++ compiler generates DW_TAG_try_block for
> >
> > try
> > {
> > ...
> > }
> >
> > Gdb can't print any local variables declared inside the try block. This
> > patch seems to work for us. Is that correct?
>
> I believe that this is correct, and that (at least for now) the same
> thing should be done for DW_TAG_catch_block. There's a PR for this
> issue.
>
You are right. We do use DW_TAG_catch_block. This also works for the
catch block.
H.J.
---
2003-05-26 H.J. Lu <hongjiu.lu@intel.com>
* dwarf2read.c (process_die): Handle DW_TAG_try_block and
DW_TAG_catch_block.
--- gdb/dwarf2read.c.try 2003-05-26 12:23:22.000000000 -0700
+++ gdb/dwarf2read.c 2003-05-26 13:07:47.000000000 -0700
@@ -1768,6 +1768,8 @@ process_die (struct die_info *die, struc
of a function and make GDB `next' properly over inlined functions. */
break;
case DW_TAG_lexical_block:
+ case DW_TAG_try_block:
+ case DW_TAG_catch_block:
read_lexical_block_scope (die, objfile, cu_header);
break;
case DW_TAG_class_type:
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: DW_TAG_try_block
2003-05-26 19:46 RFC: DW_TAG_try_block H. J. Lu
2003-05-26 19:59 ` Daniel Jacobowitz
@ 2003-05-27 14:46 ` Elena Zannoni
2003-05-27 14:58 ` H. J. Lu
1 sibling, 1 reply; 10+ messages in thread
From: Elena Zannoni @ 2003-05-27 14:46 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
H. J. Lu writes:
> Intel C++ compiler generates DW_TAG_try_block for
>
> try
> {
> ...
> }
>
> Gdb can't print any local variables declared inside the try block. This
> patch seems to work for us. Is that correct?
>
>
> H.J.
> ---
> 2003-05-26 H.J. Lu <hongjiu.lu@intel.com>
>
> * dwarf2read.c (process_die): Handle DW_TAG_try_block.
>
> --- gdb/dwarf2read.c.try 2003-05-26 12:23:22.000000000 -0700
> +++ gdb/dwarf2read.c 2003-05-26 12:37:08.000000000 -0700
> @@ -1768,6 +1768,7 @@ process_die (struct die_info *die, struc
> of a function and make GDB `next' properly over inlined functions. */
> break;
> case DW_TAG_lexical_block:
> + case DW_TAG_try_block:
> read_lexical_block_scope (die, objfile, cu_header);
> break;
> case DW_TAG_class_type:
Seems ok, can you address Daniel's concern about the catch block?
I.e. add that as well?
How about adding a little test case to the gdb.c++ directory?
elena
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: DW_TAG_try_block
2003-05-27 14:46 ` Elena Zannoni
@ 2003-05-27 14:58 ` H. J. Lu
2003-05-27 15:05 ` Daniel Jacobowitz
2003-05-27 15:06 ` Elena Zannoni
0 siblings, 2 replies; 10+ messages in thread
From: H. J. Lu @ 2003-05-27 14:58 UTC (permalink / raw)
To: Elena Zannoni; +Cc: GDB
On Tue, May 27, 2003 at 10:47:03AM -0400, Elena Zannoni wrote:
> H. J. Lu writes:
> > Intel C++ compiler generates DW_TAG_try_block for
> >
> > try
> > {
> > ...
> > }
> >
> > Gdb can't print any local variables declared inside the try block. This
> > patch seems to work for us. Is that correct?
> >
> >
> > H.J.
> > ---
> > 2003-05-26 H.J. Lu <hongjiu.lu@intel.com>
> >
> > * dwarf2read.c (process_die): Handle DW_TAG_try_block.
> >
> > --- gdb/dwarf2read.c.try 2003-05-26 12:23:22.000000000 -0700
> > +++ gdb/dwarf2read.c 2003-05-26 12:37:08.000000000 -0700
> > @@ -1768,6 +1768,7 @@ process_die (struct die_info *die, struc
> > of a function and make GDB `next' properly over inlined functions. */
> > break;
> > case DW_TAG_lexical_block:
> > + case DW_TAG_try_block:
> > read_lexical_block_scope (die, objfile, cu_header);
> > break;
> > case DW_TAG_class_type:
>
>
> Seems ok, can you address Daniel's concern about the catch block?
> I.e. add that as well?
http://sources.redhat.com/ml/gdb/2003-05/msg00348.html
> How about adding a little test case to the gdb.c++ directory?
>
I can provide a simple C++ code. But you will need Intel C++ compiler to
see the problem. Also the current Intel compiler doesn't support RedHat
9.
H.J.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: DW_TAG_try_block
2003-05-27 14:58 ` H. J. Lu
@ 2003-05-27 15:05 ` Daniel Jacobowitz
2003-05-27 15:06 ` Elena Zannoni
1 sibling, 0 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2003-05-27 15:05 UTC (permalink / raw)
To: H. J. Lu; +Cc: Elena Zannoni, GDB
On Tue, May 27, 2003 at 07:57:36AM -0700, H. J. Lu wrote:
> On Tue, May 27, 2003 at 10:47:03AM -0400, Elena Zannoni wrote:
> > H. J. Lu writes:
> > > Intel C++ compiler generates DW_TAG_try_block for
> > >
> > > try
> > > {
> > > ...
> > > }
> > >
> > > Gdb can't print any local variables declared inside the try block. This
> > > patch seems to work for us. Is that correct?
> > >
> > >
> > > H.J.
> > > ---
> > > 2003-05-26 H.J. Lu <hongjiu.lu@intel.com>
> > >
> > > * dwarf2read.c (process_die): Handle DW_TAG_try_block.
> > >
> > > --- gdb/dwarf2read.c.try 2003-05-26 12:23:22.000000000 -0700
> > > +++ gdb/dwarf2read.c 2003-05-26 12:37:08.000000000 -0700
> > > @@ -1768,6 +1768,7 @@ process_die (struct die_info *die, struc
> > > of a function and make GDB `next' properly over inlined functions. */
> > > break;
> > > case DW_TAG_lexical_block:
> > > + case DW_TAG_try_block:
> > > read_lexical_block_scope (die, objfile, cu_header);
> > > break;
> > > case DW_TAG_class_type:
> >
> >
> > Seems ok, can you address Daniel's concern about the catch block?
> > I.e. add that as well?
>
> http://sources.redhat.com/ml/gdb/2003-05/msg00348.html
>
> > How about adding a little test case to the gdb.c++ directory?
> >
>
> I can provide a simple C++ code. But you will need Intel C++ compiler to
> see the problem. Also the current Intel compiler doesn't support RedHat
> 9.
That's good enough - I'd appreciate it if you would post an appropriate
testcase or at least test program.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: DW_TAG_try_block
2003-05-27 14:58 ` H. J. Lu
2003-05-27 15:05 ` Daniel Jacobowitz
@ 2003-05-27 15:06 ` Elena Zannoni
2003-05-27 15:19 ` H. J. Lu
1 sibling, 1 reply; 10+ messages in thread
From: Elena Zannoni @ 2003-05-27 15:06 UTC (permalink / raw)
To: H. J. Lu; +Cc: Elena Zannoni, GDB
H. J. Lu writes:
> On Tue, May 27, 2003 at 10:47:03AM -0400, Elena Zannoni wrote:
> > H. J. Lu writes:
> > > Intel C++ compiler generates DW_TAG_try_block for
> > >
> > > try
> > > {
> > > ...
> > > }
> > >
> > > Gdb can't print any local variables declared inside the try block. This
> > > patch seems to work for us. Is that correct?
> > >
> > >
> > > H.J.
> > > ---
> > > 2003-05-26 H.J. Lu <hongjiu.lu@intel.com>
> > >
> > > * dwarf2read.c (process_die): Handle DW_TAG_try_block.
> > >
> > > --- gdb/dwarf2read.c.try 2003-05-26 12:23:22.000000000 -0700
> > > +++ gdb/dwarf2read.c 2003-05-26 12:37:08.000000000 -0700
> > > @@ -1768,6 +1768,7 @@ process_die (struct die_info *die, struc
> > > of a function and make GDB `next' properly over inlined functions. */
> > > break;
> > > case DW_TAG_lexical_block:
> > > + case DW_TAG_try_block:
> > > read_lexical_block_scope (die, objfile, cu_header);
> > > break;
> > > case DW_TAG_class_type:
> >
> >
> > Seems ok, can you address Daniel's concern about the catch block?
> > I.e. add that as well?
>
> http://sources.redhat.com/ml/gdb/2003-05/msg00348.html
>
oh, ok then.
> > How about adding a little test case to the gdb.c++ directory?
> >
>
> I can provide a simple C++ code. But you will need Intel C++ compiler to
> see the problem. Also the current Intel compiler doesn't support RedHat
> 9.
>
Hmm, maybe just post the example code then.
elena
>
> H.J.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: DW_TAG_try_block
2003-05-27 15:06 ` Elena Zannoni
@ 2003-05-27 15:19 ` H. J. Lu
2003-05-28 16:47 ` David Carlton
0 siblings, 1 reply; 10+ messages in thread
From: H. J. Lu @ 2003-05-27 15:19 UTC (permalink / raw)
To: Elena Zannoni; +Cc: GDB
On Tue, May 27, 2003 at 11:12:12AM -0400, Elena Zannoni wrote:
> > > How about adding a little test case to the gdb.c++ directory?
> > >
> >
> > I can provide a simple C++ code. But you will need Intel C++ compiler to
> > see the problem. Also the current Intel compiler doesn't support RedHat
> > 9.
> >
>
> Hmm, maybe just post the example code then.
>
> elena
>
When it is compiled by ecc 7.1,
# ecc -g main.cc -o main
The current gdb won't see ni nor n when break points are set in try
and catch blocks.
H.J.
-----
#include <iostream>
#include <stdexcept>
using namespace std;
int main(int argc, char* argv[])
{
try {
int ni = 2;
if (ni)
cout << "scatt: " << ni << endl;
throw "Good: ";
exit(EXIT_SUCCESS);
} catch(runtime_error& e) {
cerr << "scatt: runtime error occured.\n";
exit(EXIT_FAILURE);
}
catch (const char *p)
{
int n;
n = 3;
cerr << p << n << endl;
exit(EXIT_FAILURE);
}
}
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: DW_TAG_try_block
2003-05-27 15:19 ` H. J. Lu
@ 2003-05-28 16:47 ` David Carlton
2003-05-28 16:50 ` Daniel Jacobowitz
0 siblings, 1 reply; 10+ messages in thread
From: David Carlton @ 2003-05-28 16:47 UTC (permalink / raw)
To: H. J. Lu; +Cc: Elena Zannoni, GDB
On Tue, 27 May 2003 08:13:34 -0700, "H. J. Lu" <hjl@lucon.org> said:
> When it is compiled by ecc 7.1,
> # ecc -g main.cc -o main
> The current gdb won't see ni nor n when break points are set in try
> and catch blocks.
[ Source code deleted, but thanks. ]
I was going to volunteer to add this to the test suite, but it looks
like something like that is already there: am I correct in thinking
that gdb.c++/try-catch.exp fails if you're using ecc as your compiler?
(How do you tell runtest to use a different C compiler, anyways? Does
"CC=ecc runtest gdb.c++/try-catch.exp" work?)
David Carlton
carlton@math.stanford.edu
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: DW_TAG_try_block
2003-05-28 16:47 ` David Carlton
@ 2003-05-28 16:50 ` Daniel Jacobowitz
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2003-05-28 16:50 UTC (permalink / raw)
To: David Carlton; +Cc: H. J. Lu, Elena Zannoni, GDB
On Wed, May 28, 2003 at 09:46:48AM -0700, David Carlton wrote:
> On Tue, 27 May 2003 08:13:34 -0700, "H. J. Lu" <hjl@lucon.org> said:
>
> > When it is compiled by ecc 7.1,
>
> > # ecc -g main.cc -o main
>
> > The current gdb won't see ni nor n when break points are set in try
> > and catch blocks.
>
> [ Source code deleted, but thanks. ]
>
> I was going to volunteer to add this to the test suite, but it looks
> like something like that is already there: am I correct in thinking
> that gdb.c++/try-catch.exp fails if you're using ecc as your compiler?
> (How do you tell runtest to use a different C compiler, anyways? Does
> "CC=ecc runtest gdb.c++/try-catch.exp" work?)
No; I have to create a custom board file and use "set board_info
c++compiler ecc" or the equivalent. Fixing it to recognize
CC_FOR_TARGET is on my list somewhere.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-05-28 16:50 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-26 19:46 RFC: DW_TAG_try_block H. J. Lu
2003-05-26 19:59 ` Daniel Jacobowitz
2003-05-26 20:16 ` H. J. Lu
2003-05-27 14:46 ` Elena Zannoni
2003-05-27 14:58 ` H. J. Lu
2003-05-27 15:05 ` Daniel Jacobowitz
2003-05-27 15:06 ` Elena Zannoni
2003-05-27 15:19 ` H. J. Lu
2003-05-28 16:47 ` David Carlton
2003-05-28 16:50 ` Daniel Jacobowitz
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).