Re: gfortran - gdb problem

Re: gfortran - gdb problem

[Wu Zhou]

> $gdb ./a.out
> GNU gdb 6.3-debian
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
> 
> (gdb) l
> 1       ../sysdeps/i386/elf/start.S: No such file or directory.
>         in ../sysdeps/i386/elf/start.S
> (gdb)
> 
> 
> Normally, 'l' should display the source code. But it is giving some
> error. I am using debian sid, kernel 2.6.9-1-686. I tested the same
> thing with a helloworld program written in c and gdb works fine there.
>  
> 1) I am wondering whether it is a bug in either gdb or gfortran or
> packging of gfortran on Debian or some other thing?

Maybe it is a packaging problem.  On my Fedora Core 4, it shows the 
following text:

(gdb) l
5          We call it from the main() function in this file.  */
6       void MAIN__ (void);
7
8       /* Main procedure for fortran programs.  All we do is set up the environment
9          for the Fortran program.  */
10      int
11      main (int argc, char *argv[])
12      {
13        /* Set up the runtime environment.  */
14        set_args (argc, argv);

> 
> 2) Could anyone reproduce this?

I ever encountered similar problems on PPC platform.

Regards
- Wu Zhou

Re: gfortran - gdb problem

[Daniel Jacobowitz]

On Fri, Jul 22, 2005 at 05:43:51PM +0800, Wu Zhou wrote:
> > (gdb) l
> > 1       ../sysdeps/i386/elf/start.S: No such file or directory.
> >         in ../sysdeps/i386/elf/start.S

This happens if you have debugging information for start.S, but not for
main.

> Maybe it is a packaging problem.  On my Fedora Core 4, it shows the 
> following text:
> 
> (gdb) l
> 5          We call it from the main() function in this file.  */
> 6       void MAIN__ (void);
> 7
> 8       /* Main procedure for fortran programs.  All we do is set up the environment
> 9          for the Fortran program.  */
> 10      int
> 11      main (int argc, char *argv[])
> 12      {
> 13        /* Set up the runtime environment.  */
> 14        set_args (argc, argv);

This happens if you have debugging information for libfortran.

Really, GDB ought to know that the main function in a Fortran program
is named MAIN__ and set that to the default location.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gfortran - gdb problem

[Wu Zhou]

> Really, GDB ought to know that the main function in a Fortran program
> is named MAIN__ and set that to the default location.

Daniel, thanks for the pointer.  I am trying to code a patch to fix this, 
but encounter another problem: when GDB tries to lookup "MAIN__" in the 
symtabs, it transfers "MAIN__" to lower cases first, so 

  lookup_symbol (main_name (), 0, VAR_DOMAIN, 0, NULL)

failed.  This attributes to the following code in symtab.c:

  if (case_sensitivity == case_sensitive_off)
    {
      char *copy;
      int len, i;

      len = strlen (name);
      copy = (char *) alloca (len + 1);
      for (i= 0; i < len; i++)
        copy[i] = tolower (name[i]);
      copy[len] = 0;
      modified_name = copy;
    }

My question here is: is it desirable to transfer the name to lower-case if 
the language is case insensitive.  My point is that the compiler could handle 
this and GDB needs only to handle what we get from the compiler.  

As for this case, I don't know how other case-insensitive languages behave. 
But it might helps to change the conditional expression to:

  case_sensitivity == case_sensitive_off && current_language->la_language != language_fortran

What do you think?  If there is any error, please correct me.  Thanks.

Regards
- Wu Zhou

Re: gfortran - gdb problem

[Daniel Jacobowitz]

On Sat, Jul 23, 2005 at 03:43:58AM +0800, Wu Zhou wrote:
> My question here is: is it desirable to transfer the name to lower-case if 
> the language is case insensitive.  My point is that the compiler could handle 
> this and GDB needs only to handle what we get from the compiler.  

Generally it's the other way round: GDB must cope with whatever strange
things the compiler produces.

> As for this case, I don't know how other case-insensitive languages behave. 
> But it might helps to change the conditional expression to:
> 
>   case_sensitivity == case_sensitive_off && current_language->la_language != language_fortran
> 
> What do you think?  If there is any error, please correct me.  Thanks.

No; adding checks specific to the language is almost always wrong.  The
only case insensitive languages in the GDB source tree are Scheme (and
I don't think the Scheme support has worked in many years) and Fortran. 
So disabling it for Fortran is about the same as deleting the code
entirely.

Here's the original patch:
  http://sourceware.org/ml/gdb-patches/2000-08/msg00025.html

Presumably, whatever HP Fortran compiler Jimmy Guo was trying to add
support for always generated symbols in lowercase, so this was
sufficient.  gfortran doesn't.  It appears to use case somewhat
inconsistently.

The fact is, our symbol table does not support case insensitive lookup.
I suppose one cheap solution to this would be to lower case based on CU
language when reading in the symbol table, but that's not a very pretty
solution.  Perhaps Elena (the symbol table maintainer) has another idea.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gfortran - gdb problem

[David Lecomber]

> The fact is, our symbol table does not support case insensitive lookup.
> I suppose one cheap solution to this would be to lower case based on CU
> language when reading in the symbol table, but that's not a very pretty
> solution.  Perhaps Elena (the symbol table maintainer) has another idea.

It's presently got a bit of a mix up..  If you look in symtab.c's
lookup_symbol, you see it checks the language's sensitivity and converts
to lower case if so.

However, if you look at what any of the code which adds symbols does,
none of it actually converts any fortran symbols to lower case before
putting them in the table.  Result, total mess up if your compiler
happens to put things in upper case in the dwarf section, for example
(such as Absoft).  Most compilers I've seen generate only lower case for
Fortran.

Cheers
David
-- 
David Lecomber 
CTO Allinea Software
Tel: +44 1926 623231
Fax: +44 1926 623232

Re: gfortran - gdb problem

[Wu Zhou]

On Mon, 25 Jul 2005, Daniel Jacobowitz wrote:

> No; adding checks specific to the language is almost always wrong.  The
> only case insensitive languages in the GDB source tree are Scheme (and
> I don't think the Scheme support has worked in many years) and Fortran. 
> So disabling it for Fortran is about the same as deleting the code
> entirely.

OK.  I cancel this method.  I don't know the big picture before.

> 
> Here's the original patch:
>   http://sourceware.org/ml/gdb-patches/2000-08/msg00025.html
> 
> Presumably, whatever HP Fortran compiler Jimmy Guo was trying to add
> support for always generated symbols in lowercase, so this was
> sufficient.  gfortran doesn't.  It appears to use case somewhat
> inconsistently.
> 
> The fact is, our symbol table does not support case insensitive lookup.
> I suppose one cheap solution to this would be to lower case based on CU
> language when reading in the symbol table, but that's not a very pretty
> solution.  Perhaps Elena (the symbol table maintainer) has another idea.

IMHO, the case insensitive lookup might be the long-term resolution.  What 
about define "strcmp" as an macro of "strcasecmp" if case_sensitive is 
false?  This might seems ugly, but it should help here.

Regards
- Wu Zhou

Re: gfortran - gdb problem

[Daniel Jacobowitz]

On Sat, Jul 23, 2005 at 04:47:11AM +0800, Wu Zhou wrote:
> IMHO, the case insensitive lookup might be the long-term resolution.  What 
> about define "strcmp" as an macro of "strcasecmp" if case_sensitive is 
> false?  This might seems ugly, but it should help here.

You should take a look at the symbol table structures first - it's not
that simple.  Most of it is hashed case-sensitively.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gfortran - gdb problem

[Wu Zhou]

On Tue, 26 Jul 2005, Daniel Jacobowitz wrote:

> On Sat, Jul 23, 2005 at 04:47:11AM +0800, Wu Zhou wrote:
> > IMHO, the case insensitive lookup might be the long-term resolution.  What 
> > about define "strcmp" as an macro of "strcasecmp" if case_sensitive is 
> > false?  This might seems ugly, but it should help here.
> 
> You should take a look at the symbol table structures first - it's not
> that simple.  Most of it is hashed case-sensitively.

Yes.  You are right.  I run to this point too fast.

What about the other method you suggested: to lower case based on CU
language when reading in the symbol table?  If it is okay, maybe I can try 
to code a patch on this.  

Elena, what is your idea on this?  Daniel said that you might have better 
idea. 

Regards
- Wu Zhou