SOFUN_ADDRESS_MAYBE_MISSING

SOFUN_ADDRESS_MAYBE_MISSING

[Mark Kettenis]

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

Re: SOFUN_ADDRESS_MAYBE_MISSING

[Kevin Buettner]

On Oct 6,  2:42pm, Mark Kettenis wrote:

> 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.

It's been a while since I've studied this problem, but the last time
I looked at it, enabling SOFUN_ADDRESS_MAYBE_MISSING for all targets
looked pretty safe to me.

Kevin

Re: SOFUN_ADDRESS_MAYBE_MISSING

[Jim Blandy]

Kevin Buettner <kevinb@redhat.com> writes:

> On Oct 6,  2:42pm, Mark Kettenis wrote:
> 
> > 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.
> 
> It's been a while since I've studied this problem, but the last time
> I looked at it, enabling SOFUN_ADDRESS_MAYBE_MISSING for all targets
> looked pretty safe to me.

I'd go along with that.  Let's just try enabling it for all targets,
and deal with the fallout.

Re: SOFUN_ADDRESS_MAYBE_MISSING

[Jim Blandy]

Mark Kettenis <kettenis@chello.nl> 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.

Not that this is germane to the issue you're trying to fix, but:

SOFUN_ADDRESS_MAYBE_MISSING isn't a bug --- it's a feature.  Sun made
various adjustments to make fewer stabs require relocation, to reduce
link time.  That's why line number stabs are relative to the beginning
of the function, for example.  Since every function has a linker
symbol for its entry point, and there are STT_FILE symbols for the
compilation units (I think I've got that right), there's no real need
to put the address in the SO and FUN stabs, too.

Re: SOFUN_ADDRESS_MAYBE_MISSING

[Elena Zannoni]

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

Re: SOFUN_ADDRESS_MAYBE_MISSING

[Mark Kettenis]

   From: Elena Zannoni <ezannoni@redhat.com>
   Date: Wed, 15 Oct 2003 14:32:52 -0400

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

See the thread starting with:

http://sources.redhat.com/ml/binutils/1999-q3/msg00635.html

There was a change/bug in binutils that produces zero-valued N_FUN
stabs.  AFAICR there never was an official binutils release that
suffered from the problem, however there were versions HJ Lu's
binutils for Linux in use that suffered from the problem, which
explains why it's only enabled on Linux and not on other platforms
that use binutils as part of their native toolchain.

Mark

Re: SOFUN_ADDRESS_MAYBE_MISSING

[Michael Elizabeth Chastain]

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

BTW, you might already know this, but you can run stabs+ on RH 9 with:

  runtest ... --target_board unix/gdb:debug_flags=-gstabs+

I don't know the right incantation for doing this at the
"make check" level.

eza> This would require to increase the size of a minsym in all
eza> cases, by making this unconditional:

My data point is that minsym size is not important: about 0.3 megabytes
out of 80 megabytes with "gdb --readnow gdb".  Dunno about the normal
case without "--readnow" but I wouldn't worry about increasing the
size of a minsym if that helps fix a problem.

My two superficial observations,

Michael C