Another Fortran problem...

Hi all,

I take as an example a Fortran source file containing en
empty
subroutine and an empty program:

$ cat a.f90
  subroutine foo
  end subroutine foo
  program bar
  end

When I compile it with gfortran and load it into gdb, I
can't set
breakpoints on "foo", but only on "foo_"
(which is the mangled name).
I was looking into why gfortran doesn't emit the necessary
debug info,
but I think it actually does. The relevant output from
readelf says:

 <1><19c>: Abbrev Number: 2 (DW_TAG_subprogram)
     DW_AT_external    : 1
     DW_AT_name        : foo
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 1
     DW_AT_MIPS_linkage_name: foo_
     DW_AT_low_pc      : 0x4005fc
     DW_AT_high_pc     : 0x400602
     DW_AT_frame_base  : 0      (location list)

Now, what I don't understand is when I compile it with the
Intel
compiler, it's possible to set breakpoints on
"foo" as well as "foo_",
even though the debug info seems similar:

 <1><187>: Abbrev Number: 3 (DW_TAG_subprogram)
     DW_AT_decl_line   : 1
     DW_AT_decl_column : 12
     DW_AT_decl_file   : 1
     DW_AT_inline      : 0      (not inlined)
     DW_AT_accessibility: 1     (public)
     DW_AT_type        : <17f>
     DW_AT_prototyped  : 0
     DW_AT_name        : foo
     DW_AT_low_pc      : 0x4028f0
     DW_AT_high_pc     : 0x4028f6
     DW_AT_external    : 1

Is "DW_AT_MIPS_linkage_name: foo_" the reason for
this difference?
Should DW_AT_MIPS_linkage_name actually be emitted or is
this wrong?

Thanks for your help,
FX

PS: please find attached the complete readelf output for
both
compilers, I case more information is needed.

On Fri, Oct 26, 2007 at 11:39:11AM +0100, Fran?ois-Xavier
Coudert wrote:
> Is "DW_AT_MIPS_linkage_name: foo_" the reason
for this difference?

Yes.

> Should DW_AT_MIPS_linkage_name actually be emitted or
is this wrong?

I'm not sure.  I was just looking at this problem; I have
some
in-progress patches that remove GDB's use of
DW_AT_MIPS_linkage_name,
and I was very surprised when they fixed a recent gnats PR
about
a similar Fortran problem.

"foo_" is really the linkage name, so if gfortran
wants to emit
DW_AT_MIPS_linkage_name then that's the value it should
have.  But
GDB doesn't have a demangler for Fortran mangled names so
it ends up stuck with the mangled name.

What sort of mangling does gfortran do?  Should we be able
to demangle
it?  Or just ignore linkage names for Fortran?

-- 
Daniel Jacobowitz
CodeSourcery

> "foo_" is really the linkage name, so if
gfortran wants to emit
> DW_AT_MIPS_linkage_name then that's the value it should
have.  But
> GDB doesn't have a demangler for Fortran mangled names
so
> it ends up stuck with the mangled name.

I've looked into GCC, and it emits DW_AT_MIPS_linkage_name
every time
it sees a function with a linkage name different from its
source name.

The Fortran mangling scheme depends on the compiler and
compiler
options used, so I don't think a demangler is possible. Even
for a
given compiler with default options, Fortran 2003 made it
possible to
specifiy arbitrary linkage names to procedures. A subroutine
declared
like that:

  subroutine foo() bind(c,name="bar")

will have the following

     DW_AT_name        : foo
     DW_AT_MIPS_linkage_name: bar

Moreover, it's possible to give two procedures identical
names, with
different linkage names:

$ cat u.f90
subroutine foo() bind(c,name="bar")
end subroutine foo
$ cat v.f90
subroutine foo() bind(c,name="gee")
end subroutine foo
end
$ gfortran u.f90 v.f90
$ readelf -wi ./a.out | egrep '(foo|bar|gee)'
     DW_AT_name        : foo
     DW_AT_MIPS_linkage_name: bar
     DW_AT_name        : foo
     DW_AT_MIPS_linkage_name: gee


What I would consider the best behaviour for gdb is that it
considers
both source names and linkage names, and in case of an
ambiguity
  1. between a source name and a linkage name, go for the
linkage name
  2. between two source names, ask the user to specify the
linkage
name of one of them

Of course, I don't know how hard it would be to implement
this behaviour.

FX

On Fri, Oct 26, 2007 at 02:04:56PM +0100, Fran?ois-Xavier
Coudert wrote:
> What I would consider the best behaviour for gdb is
that it considers
> both source names and linkage names, and in case of an
ambiguity
>   1. between a source name and a linkage name, go for
the linkage name
>   2. between two source names, ask the user to specify
the linkage
> name of one of them
> 
> Of course, I don't know how hard it would be to
implement this behaviour.

Somewhat impractical.  I think we would be best off ignoring
linkage
names for Fortran, or else GCC not emitting them... I don't
know
which.  Won't they generally match the names in the ELF
symbol table?
In that case they are not particularly useful for
definitions.

-- 
Daniel Jacobowitz
CodeSourcery

> Somewhat impractical.  I think we would be best off
ignoring linkage
> names for Fortran, or else GCC not emitting them... I
don't know
> which.  Won't they generally match the names in the ELF
symbol table?

Yes, they probably will. Don't they serve any other useful
purpose?
(not emitting them in GCC fixes the problem)

FX

On Fri, Oct 26, 2007 at 02:58:35PM +0100, Fran?ois-Xavier
Coudert wrote:
> > Somewhat impractical.  I think we would be best
off ignoring linkage
> > names for Fortran, or else GCC not emitting
them... I don't know
> > which.  Won't they generally match the names in
the ELF symbol table?
> 
> Yes, they probably will. Don't they serve any other
useful purpose?
> (not emitting them in GCC fixes the problem)

I'm not sure.  In C++ we use them to extract namespace and
class
hierarchy information, which was only represented in DWARF
relatively
recently (circa 3.3).  They should be unnecessary now in
most cases
and other compilers do not admit them.

I can see how they could be useful for non-defining
declarations, in
case the definition was in an object without debugging
information.

Let's give it a day or two in case anyone else has comments,
but I
don't think DW_AT_MIPS_linkage_name has any benefit for
Fortran
support.  In that case, we can change GCC HEAD not to emit
them and
GDB not to use them.

-- 
Daniel Jacobowitz
CodeSourcery