* Suggest closing some old pending PRs
@ 2005-11-03 0:13 Joel Brobecker
2005-11-04 5:02 ` Ramana Radhakrishnan
2005-11-04 10:20 ` Wu Zhou
0 siblings, 2 replies; 6+ messages in thread
From: Joel Brobecker @ 2005-11-03 0:13 UTC (permalink / raw)
To: gdb-patches
See PR 1903, for instance:
PR opened on Apr 1st, followed by a request to try a more recent GCC.
Then nothing.
Opinions?
--
Joel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggest closing some old pending PRs
2005-11-03 0:13 Suggest closing some old pending PRs Joel Brobecker
@ 2005-11-04 5:02 ` Ramana Radhakrishnan
2005-11-04 10:20 ` Wu Zhou
1 sibling, 0 replies; 6+ messages in thread
From: Ramana Radhakrishnan @ 2005-11-04 5:02 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
On Wed, 2005-11-02 at 15:00 -0800, Joel Brobecker wrote:
> See PR 1903, for instance:
>
> PR opened on Apr 1st, followed by a request to try a more recent GCC.
> Then nothing.
>
> Opinions?
>
Add to the list, PR 1975 ?
PR1961 can be closed since it no longer crashes gdb .
My vote is to close them .
Are we looking at targeting any set of PRs for the release ?
cheers
Ramana
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggest closing some old pending PRs
2005-11-03 0:13 Suggest closing some old pending PRs Joel Brobecker
2005-11-04 5:02 ` Ramana Radhakrishnan
@ 2005-11-04 10:20 ` Wu Zhou
2005-11-04 11:56 ` Wu Zhou
1 sibling, 1 reply; 6+ messages in thread
From: Wu Zhou @ 2005-11-04 10:20 UTC (permalink / raw)
To: ramana.radhakrishnan, Joel Brobecker; +Cc: gdb-patches
> Add to the list, PR 1975 ?
>
> PR1961 can be closed since it no longer crashes gdb .
>
>
> My vote is to close them .
Yes. I can close that. It is fixed by one of my patch a few monthes ago.
>
> Are we looking at targeting any set of PRs for the release ?
This reminds me that I have some patches and testcases for reviewing.
Most of them is about Fortran (77 and 95) debugging support. Could
I have the pleasure that it get reviewed and into the 6.4 release if
acceptable. Maybe I could glean a list for you maintainers to check?
I will do it today before leaving for home.
Regards
- Wu Zhou
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggest closing some old pending PRs
2005-11-04 10:20 ` Wu Zhou
@ 2005-11-04 11:56 ` Wu Zhou
2005-11-04 14:48 ` David Lecomber
0 siblings, 1 reply; 6+ messages in thread
From: Wu Zhou @ 2005-11-04 11:56 UTC (permalink / raw)
To: ramana.radhakrishnan, Joel Brobecker; +Cc: gdb-patches
On Fri, 4 Nov 2005, Wu Zhou wrote:
>
> > Add to the list, PR 1975 ?
> >
> > PR1961 can be closed since it no longer crashes gdb .
> >
> >
> > My vote is to close them .
>
> Yes. I can close that. It is fixed by one of my patch a few monthes ago.
I had just closed it.
>
> >
> > Are we looking at targeting any set of PRs for the release ?
>
> This reminds me that I have some patches and testcases for reviewing.
> Most of them is about Fortran (77 and 95) debugging support. Could
> I have the pleasure that it get reviewed and into the 6.4 release if
> acceptable. Maybe I could glean a list for you maintainers to check?
> I will do it today before leaving for home.
I had a look at all these fortran related PRs. Some are very old reports,
some are already fixed by some patches. and yet soome there is no
response. I made some changes to these reports. Some closed if I am
sure. Others are waiting for feedback. I update their status here and at
the same time ask for advice on how to proceed on some of them.
- PR 1880: display of part of an array
one of my patch could fix this partially, it can display one-dimension
array section (a.k.a sub-array). It is somewhat more difficult to
handle multi-dimension.
- PR 1768: Seg fault with large programs?
There is no testcase, no reproducible steps. And I ask for more
context around 5 monthes ago. Didn't get any reply right now. Maybe
I can clost this?
- PR 1536: gdb 6.0 works with programs compiled with g77 but not HP's f77
HP-UX 11.0
The submitter didn't response for nearly five monthes. And as far as I
know we didn't test gdb against HP's f77 compiler code. Maybe we can close
this too?
- PR 1531/1530: segmentation fault for FOTRAN77 arrays
I fixed it a few monthes ago. The submitter said ok to close it. Closed
a few monthes ago.
- PR 1074: Patches to improve Fortran support
This patch is from David Lecomber. And it was already included in another
more comprehensive one. As per David's confirmation, I had just closed
it.
- PR 648: Indexing is incorrect for printing elements of multi-dimensional
FORTRAN (g77) array
This is already fixed by David Lecomber patch (at least for DWARF reader).
And I had coded a testcase for that. Could it get into mainline and gdb-6.4 branch?
- PR 822: Finding 'main' in languages other than C/C++
This PR is opened by Elena. And I coded an intial patch to let gdb
set fortran main function to "MAIN__", which is used by both g77 and
gfortran. Although it could not resolve the error completely. It can let
gdb recoginize that the language is fortran after just loading the binary.
Could I get this into the source tree and go on to implement the case
insensitive symbol lookup for Fortran?
- PR 185: gdb can't see f77 source
The root cause of this report is the same as PR-822. So I close this as
duplicate to that.
- PR 939: GDB does not recognise debug information for fortran string correctly.
It seems that GDB didn't handle DW_TAG_string_type for Fortran code. The
reason might be that both g77 and gfortran handle the string as array of
character. That is different than ifc. To support ifc, there might be
some more work needed in gdb.
- PR 1474: incomplete type
Closed by Michael Chastain a years ago.
- PR 3: gdb segfaults associated with FORTRAN (g77) array arguments
This is closed as per submitter's comments.
OK. That is all. Now we have 6 un-closed PRs in fortran aspect. Maybe
we can also close a few of them. Could we say that gdb's support of
Fortran language is somewhat better than before, maybe in the NEW file?
I know that you are discussing that what can and what can't get into that.
I am not sure. So I am asking. :-)
I am also thinking of enhance gdb's support for new language
features introduced after Fortran 77, such as derived type, modular
handling and so on. Any suggestion on how to do that is more efficiently
and more prone to be accepted into the mainline or 6.4 release? Your
advice is highly appreciated. Thanks!
Regards
- Wu Zhou
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggest closing some old pending PRs
2005-11-04 11:56 ` Wu Zhou
@ 2005-11-04 14:48 ` David Lecomber
2005-11-04 23:26 ` Wu Zhou
0 siblings, 1 reply; 6+ messages in thread
From: David Lecomber @ 2005-11-04 14:48 UTC (permalink / raw)
To: Wu Zhou; +Cc: ramana.radhakrishnan, Joel Brobecker, gdb-patches
Hi Wu,
> - PR 648: Indexing is incorrect for printing elements of multi-dimensional
> FORTRAN (g77) array
>
> This is already fixed by David Lecomber patch (at least for DWARF reader).
> And I had coded a testcase for that. Could it get into mainline and gdb-6.4 branch?
I presume you mean the testcase ? The actual code has been mainline for
18 months at least!
> - PR 822: Finding 'main' in languages other than C/C++
>
> This PR is opened by Elena. And I coded an intial patch to let gdb
> set fortran main function to "MAIN__", which is used by both g77 and
> gfortran. Although it could not resolve the error completely. It can let
> gdb recoginize that the language is fortran after just loading the binary.
> Could I get this into the source tree and go on to implement the case
> insensitive symbol lookup for Fortran?
There are other compilers - IBM XLF, Intel IFC, Portland pgf77, and
Pathscale EKO at the very least -- and I've never been able to find a
consistent behaviour that worked across the board - regexp or otherwise
matching!!
Cheers
d.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Suggest closing some old pending PRs
2005-11-04 14:48 ` David Lecomber
@ 2005-11-04 23:26 ` Wu Zhou
0 siblings, 0 replies; 6+ messages in thread
From: Wu Zhou @ 2005-11-04 23:26 UTC (permalink / raw)
To: David Lecomber; +Cc: ramana.radhakrishnan, Joel Brobecker, gdb-patches
On Fri, 4 Nov 2005, David Lecomber wrote:
> Hi Wu,
> > - PR 648: Indexing is incorrect for printing elements of multi-dimensional
> > FORTRAN (g77) array
> >
> > This is already fixed by David Lecomber patch (at least for DWARF reader).
> > And I had coded a testcase for that. Could it get into mainline and gdb-6.4 branch?
>
> I presume you mean the testcase ? The actual code has been mainline for
> 18 months at least!
Yes. I mean the testcase.
> > - PR 822: Finding 'main' in languages other than C/C++
> >
> > This PR is opened by Elena. And I coded an intial patch to let gdb
> > set fortran main function to "MAIN__", which is used by both g77 and
> > gfortran. Although it could not resolve the error completely. It can let
> > gdb recoginize that the language is fortran after just loading the binary.
> > Could I get this into the source tree and go on to implement the case
> > insensitive symbol lookup for Fortran?
>
> There are other compilers - IBM XLF, Intel IFC, Portland pgf77, and
> Pathscale EKO at the very least -- and I've never been able to find a
> consistent behaviour that worked across the board - regexp or otherwise
> matching!!
Yes. It is hard to find a consistent way to handle this. What is the
situation in C, c++ or other language fields? Maybe we need a similar
thing like c++ ABI or something else. If we can't get any input from these
proprietary compiler, we can only make it work for g77 and gfortran.
Regards
- Wu Zhou
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-11-04 14:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-03 0:13 Suggest closing some old pending PRs Joel Brobecker
2005-11-04 5:02 ` Ramana Radhakrishnan
2005-11-04 10:20 ` Wu Zhou
2005-11-04 11:56 ` Wu Zhou
2005-11-04 14:48 ` David Lecomber
2005-11-04 23:26 ` Wu Zhou
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox