Re: SOFUN_ADDRESS_MAYBE_MISSING

[Elena Zannoni <ezannoni at redhat dot com>]

Mark Kettenis writes:
 > I'm wondering what to do with SOFUN_ADDRESS_MAYBE_MISSING.  It started
 > out (and still largely is) a hack to work around a problem with
 > stabs-in-ELF with Sun's C compiler.  Later it also got enabled on some
 > Linux variants, to work around a bug in HJ's Linux binutils IIRC.
 > 
 > The safest thing to do is probably to turn this into a multi-arch
 > variable, and set that variable for all targets that #define
 > SOFUN_ADDRESS_MAYBE_MISSING.  I winder however, what the impact would
 > be of enabling this on all ELF targets, since that would make it
 > easier to debug object modules created with the Sun compiler to
 > FreeBSD/sparc64 for example.
 > 
 > Mark

[odd, this thread seems to have not been archived in
sources.redhat.com/ml/gdb]

Let me take a different view on this.  The definitions of
SOFUN_ADDRESS_MAYBE_MISSING are on ppc/linux, i386/linux,
i386/solaris2, sparc/solaris2, and deal with problems with the stabs
debug info. However, i386/linux now uses dwarf2, and so does ppc/linux.

Can anybody reproduce the original problem with shared libraries,
which appears to have been the motivation behind defining SOFUN_... on
the Linux platforms?

I tried *deleting* the definition of SOFUN_ADDRESS_.. in
config/i386/tm-linux.h, and I ran the testsuite both on a stabs platform
(RH 7.3) and a dwarf2 platform (RH 9) and found no differences in the
testsuite results, before and after the change (of course there are
the usual differences between the stabs and the dwarf2 runs).

Anyway, at closer inspection, and looking back:
There has been some discussion one year ago about this.
http://sources.redhat.com/ml/gdb-patches/2002-04/msg00836.html
A couple of patches were contributed towards elimination of the macro, but
we ended up committing only one of them.

Summarizing, at that time, Kevin raised the objection that enabling
the SOFUN code everywhere may make us lose the ability to have symbols
at address 0.  Is this still a concern for some embedded targets? From
the old thread it appears that it was decided it was an acceptable
risk.

The approach we were converging upon at that time was to do a 2 phase
checkin, the first to eliminate the macro from symmisc.c, symtab.h,
minsyms.c.  This would require to increase the size of a minsym in all
cases, by making this unconditional:

#ifdef SOFUN_ADDRESS_MAYBE_MISSING
  /* Which source file is this symbol in?  Only relevant for mst_file_*.  */
  char *filename;
#endif

However, looking at the code as it is now, it seems that the old
thread was partially wrong about how to deal with this. The filename
information is used in 3 functions in minsym.c which have ifdef SOFUN_
code:

lookup_minimal_symbol_text: the SOFUN_.. code deals with the second
parameter (if not null). However there are 4 calls to this function,
and none of them passes a non-null 2nd parameter. I think we can get
rid of these, i.e. delete the code that is ifdeffed.

lookup_minimal_symbol_solib_trampoline: Again, deal with cases where
the second parameter is non-null. However, the function never really
does anything with the second paramter. And this lonely ifdef can
go. In any event, there are 4 calls to this function, and all pass
NULL as 2nd parameter.

lookup_minimal_symbol: Again, deal with the 2nd parameter being non-null.
This is called in a few places in dbxread.c with non null 2nd paramter.
I don't think this SUFUN_.. code can be eliminated yet.

So, I think I'll clean up the code that can be cleaned up, and then
take a look again. In the meantime if somebody could verify that
defining the macro has no impact on Linux, that would also give us a
better picture.

elena