DG/UX Port - Giving Up!!

DG/UX Port - Giving Up!!

[Eric Raskin]

Bad news for the two or three DG/UX people out there.... :-(

I'm giving up on the DG/UX Intel port of egcs (i586-dg-dguxR4.20MU03).  In
order to make everything work, you need to switch from the DG/UX assembler
and linker to the GNU versions.  If you don't, then the "weak" designations
don't work properly, and the stage2-to-stage3 compare operation during the
bootstrap fails.  If you do change, then you break the compiler supplied
with the base OS (which specifies some funky switches to the DG assembler in
order to fix up debugging information).  I've also found that debugging with
the new tools is completely broken -- I can't get dbx or gdb to debug
anything produced by the GNU assember/linker tools.  As a matter of fact, I
can't even get the objcopy utility to copy an ELF executable properly when
produced by any of the three compilers on my system -- gcc 2.7.2 (base OS),
gcc 2.8.1 (built myself) and egcs 19990502 snapshot.  The debugging info
gets trashed.  (I'm using binutils 2.9.1.)

Finally, I've found that the egcs C++ implementation on DG/UX won't call
global constructors/destructors from shared libraries.  It isn't just
dynamic linking using dlopen(), it's even the DG/UX version of ld.so that
won't do it.  On DG/UX, this file is called /usr/dglib/libc.so.1, for anyone
who cares to take a look at it.

So, I'm giving up on this port.  It's now beyond my abilities.  Anyone who
wishes to take it over from me can send an E-Mail to ehr@listworks.com.
I'll be happy to send along all the patches I've developed so far.
Alternatively, if anyone has any advice or quick fixes, I'll be happy to try
again.

----------------------------------------------------------------------------
----------------
Eric H. Raskin                                 Voice: 914-769-7100 x321
President, CSC Division                   Fax:    914-769-8070
The Listworks Corp.                         E-Mail: ehr@listworks.com
1 Campus Drive
Pleasantville, NY 10570

PS.  I spoke to the people at Data General.  They only support a C++
compiler sold by EPC (Edinburgh Portable Compilers).  I guess I'll have to
go buy it.  Anyone know anything about it?

Re: DG/UX Port - Giving Up!!

[Robert Lipe]

I've never seen DG/UX, but some of these sound familiar to me.

Eric Raskin wrote:

> I'm giving up on the DG/UX Intel port of egcs (i586-dg-dguxR4.20MU03).
> In order to make everything work, you need to switch from the DG/UX
> assembler and linker to the GNU versions.  If you don't, then the
> "weak" designations don't work properly, and the stage2-to-stage3
> compare operation during the bootstrap fails.  If you do change, then
> you break the compiler supplied with the base OS (which specifies
> some funky switches to the DG assembler in order to fix up debugging
> information).

It is entirely possible to have the GNU assembler and the native
assembler on the same system if that's what you're asking.  If the issue
is that you need to GCC to call the two assemblers with different flags,
there is prior art for that, too.  (Look in configure.in and search for
"sco5gas".  If configured --with-gnu-as that target will forget about
all the funky flags to pass to the assembler and instead use a set that
will work with GAS.  Note how sco5gas.h just sets a flag and "wraps" the
current sco5.h.)

> I've also found that debugging with the new tools is completely
> broken -- I can't get dbx or gdb to debug anything produced by the
> GNU assember/linker tools.  As a matter of fact, I can't even get the
> objcopy utility to copy an ELF executable properly when produced by
> any of the three compilers on my system -- gcc 2.7.2 (base OS), gcc
> 2.8.1 (built myself) and egcs 19990502 snapshot.  The debugging info
> gets trashed.  (I'm using binutils 2.9.1.)

You may be able to tinker with the debugging formats used.  If you have
an all-GNU toolchain (and compatibility with the native chain isn't
important), stabs are probably the thing to use.  The way I read dgux.h, 
it prefers to use DWARF1 but does also build in stabs.   Try turning that
on (using -gstabs) and see if it makes life better for you.  If you like
it, then just configure your tree with --with-stabs to make it the default.

In general, I found that trying to debug everything (gcc, ld, as, gdb)
at once was really hard.  I'd focus on getting the compiler to work well
enough to do a bootstrap with native binary tools then iterate over the 
debugger and GNU binutils to bring those up.

Of course, there are those on the list that scoff at such things since
they're so studly as to be able to effectively debug all those things in
parallel while using an system with bad RAMs. :-)


> Finally, I've found that the egcs C++ implementation on DG/UX won't
> call global constructors/destructors from shared libraries.  It
> isn't just dynamic linking using dlopen(), it's even the DG/UX
> version of ld.so that won't do it.  On DG/UX, this file is called
> /usr/dglib/libc.so.1, for anyone who cares to take a look at it.

We had (and fixed!) this very problem in OpenServer just before 1.1.2
went out.  Look in the Feb egcs-bugs archives for the threads:

	Final patch for shared library problem in SCO OpenServer
	shared library patch for SCO OpenServer 5.0.5 & egcs

If yours is an ELF-based SVR4-ish systems (and I think it is) you might
find this to be pertinent.

It may be as simple as ensuring that crti.o abd crtn.o get linked in
the right places if your system provides these.

> So, I'm giving up on this port.  It's now beyond my abilities.

It doesn't sound like you're that far from the finish line, really.


RJL

RE: DG/UX Port - Giving Up!!

[Eric Raskin]

Robert:

 Thanks for the reply...

>
> It is entirely possible to have the GNU assembler and the native
> assembler on the same system if that's what you're asking.
> If the issue
> is that you need to GCC to call the two assemblers with
> different flags,
> there is prior art for that, too.  (Look in configure.in and
> search for
> "sco5gas".  If configured --with-gnu-as that target will forget about
> all the funky flags to pass to the assembler and instead use
> a set that
> will work with GAS.  Note how sco5gas.h just sets a flag and
> "wraps" the
> current sco5.h.)

The problem is a little different, I think.  In order to build egcs, I
needed to use the GNU assembler.  However, the GNU assembler won't accept
the -W,a switches that the DG assembler needs.  So, I guess the right thing
to do is to configure egcs to run the assembler and linker from
/usr/local/bin and leave /usr/bin alone.  It's not really that I needed to
target two assemblers from the same compiler.  It's that I needed to run a
different assembler from each compiler.

> You may be able to tinker with the debugging formats used.
> If you have
> an all-GNU toolchain (and compatibility with the native chain isn't
> important), stabs are probably the thing to use.  The way I
> read dgux.h,
> it prefers to use DWARF1 but does also build in stabs.   Try
> turning that
> on (using -gstabs) and see if it makes life better for you.
> If you like
> it, then just configure your tree with --with-stabs to make
> it the default.
>

I just tried your suggestion.  No change.  I get the following from gdb when
I try to execute a program that works properly.

$ eg++ -gstabs -o goodtest goodtest.C

$ gdb goodtest
$ GNU gdb 4.18
Copyright 1998 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 "i586-dg-dguxR4.20MU03"...
(gdb) break main
Breakpoint 1 at 0x8048d7a: file goodtest.C, line 34.
(gdb) run
Starting program: /lw/downloads/mico/bug/goodtest
Don't know how to run.  Try "help target".
(gdb)

As you can see, gdb seems to be able to read some of the debugging
information (witness the breakpoint), but it can't run the file.  How
strange!  When I try to use dbx instead, I get:

$ dbx goodtest
Type "help" for a list of commands
Processing object: /lw/downloads/mico/bug/goodtest
Updating linker symbol table...641 symbols added. (Total: 641)
Updating symbolic debugging information...0 modules added. (Total: 0)
Processing object: /usr/dglib/libc.so.1
Updating linker symbol table...1768 symbols added. (Total: 2409)
Updating symbolic debugging information...0 modules added. (Total: 0)
(dbx) stop in main
(0) stop in main
(dbx) run
Starting program: /lw/downloads/mico/bug/goodtest

In Global Constructor
(0) Stopped at pc 0x8048d74 (main)
*       0x8048d74 main  pushl   %ebp
(dbx)

The program only executes at the assembler level -- no source code debugging
allowed!  When I switch back to using the DG assembler, dbx works fine, but
gdb still fails the same way.  Of course, then I'll fail some of the
testsuite.  So:  Debugging XOR correct compilation!

> In general, I found that trying to debug everything (gcc, ld, as, gdb)
> at once was really hard.  I'd focus on getting the compiler
> to work well
> enough to do a bootstrap with native binary tools then
> iterate over the
> debugger and GNU binutils to bring those up.
>

I had to do this in reverse, since I couldn't get a clean egcs build with
the native assembler -- the stage2-to-stage3 compare fails.  This compare
succeeds and all the libraries build properly when I switch to GNU
assembler.  So, I have to build the binutils first, then the compiler.  Note
that I **do** have a successful compiler build, just without debugging!

> > Finally, I've found that the egcs C++ implementation on DG/UX won't
> > call global constructors/destructors from shared libraries.  It
> > isn't just dynamic linking using dlopen(), it's even the DG/UX
> > version of ld.so that won't do it.  On DG/UX, this file is called
> > /usr/dglib/libc.so.1, for anyone who cares to take a look at it.
>
> We had (and fixed!) this very problem in OpenServer just before 1.1.2
> went out.  Look in the Feb egcs-bugs archives for the threads:
>
> 	Final patch for shared library problem in SCO OpenServer
> 	shared library patch for SCO OpenServer 5.0.5 & egcs
>
> If yours is an ELF-based SVR4-ish systems (and I think it is)
> you might
> find this to be pertinent.
>

crti.o was being linked, but objdump --disassemble showed nothing in it.
I'm rebuilding with similar patches to the SCO platform (getting crti.o
built), which I'll manually install in place of the crti.o on my ssytem.
I'll let you know if it helps.

> It may be as simple as ensuring that crti.o abd crtn.o get linked in
> the right places if your system provides these.
>
> > So, I'm giving up on this port.  It's now beyond my abilities.
>
> It doesn't sound like you're that far from the finish line, really.
>

Funny -- it seems a million miles away ! :-)

>
> RJL
>

Re: DG/UX Port - Giving Up!!

[Robert Lipe]

> The problem is a little different, I think.  In order to build egcs,
> I needed to use the GNU assembler.  However, the GNU assembler won't
> accept the -W,a switches that the DG assembler needs.  So, I guess the
> right thing to do is to configure egcs to run the assembler and linker
> from /usr/local/bin and leave /usr/bin alone.  It's not really that I
> needed to target two assemblers from the same compiler.  It's that I
> needed to run a different assembler from each compiler.

That's what I was suggesting.

It's possible to have different EGCS installations each using different
assemblers.  If you combine this with the idea of actually *telling*
dgux.h about this, you can easily wire it to use /bin/as with DGUX-ish
switchs and (via --with-gnu-as) to use some other assembler with
different flags.


> (gdb) run
> Starting program: /lw/downloads/mico/bug/goodtest
> Don't know how to run.  Try "help target".
> (gdb)
> 
> As you can see, gdb seems to be able to read some of the debugging
> information (witness the breakpoint), but it can't run the file.  

Actually, I doubt that GDB had to know any _debugging_ information to
set the breakpoint.  I could have gotten all the info it needed just
from the symbol table.

As for GDB not knowing how to run the binary in question, that's
orthogonal to the debugging info.  GDB can run programs with _no_
debugging info (or even symbol tables) so that is a different issue.

My guess is that somewhere somehow, the resulting object file is
slightly different in something like an OS version stamp.  Perhaps
comparing the output from the two files via a gdb 'info file' is in
order.  Be sure, too, that GDB can debug programs that aren't built by
this chain at all - it sounds entirely possible that your GDB is just
broken.

> The program only executes at the assembler level -- no source code debugging
> allowed!  When I switch back to using the DG assembler, dbx works fine, but
> gdb still fails the same way.  Of course, then I'll fail some of the
> testsuite.  So:  Debugging XOR correct compilation!

I think I'd focus first on using the DG assembler and figuring out the
deal with GDB.  Only then (when you have a functioning debugger) go back
and add the necessary stuff for --with-gnu-as.

Other than the bootstrap comparison errors (which might be a red
herring), do you have any reason to think that the native assembler is
actually bad?

> crti.o was being linked, but objdump --disassemble showed nothing in it.

Right.  It is an empty file, meant only to add one symbol.

> > It doesn't sound like you're that far from the finish line, really.
> Funny -- it seems a million miles away ! :-)

Maybe my standards are just low, but there are a lot of people that can
do a day's work without [cd]tors in dynamic objects and debugging info.

If you're getting executables out of it that work (and you must be if
you're even making it to the third stage) I suggest there is value in
your work.

RJL

RE: DG/UX Port - Giving Up!!

[Eric Raskin]

>
> Actually, I doubt that GDB had to know any _debugging_ information to
> set the breakpoint.  I could have gotten all the info it needed just
> from the symbol table.
>

My assumption was since that gdb knew the source code file and line, that it
must be able to read something in the debugging info.  Is that in the symbol
table?

> As for GDB not knowing how to run the binary in question, that's
> orthogonal to the debugging info.  GDB can run programs with _no_
> debugging info (or even symbol tables) so that is a different issue.
>

OK -- I'll have to look into that.

> My guess is that somewhere somehow, the resulting object file is
> slightly different in something like an OS version stamp.  Perhaps
> comparing the output from the two files via a gdb 'info file' is in
> order.  Be sure, too, that GDB can debug programs that aren't built by
> this chain at all - it sounds entirely possible that your GDB is just
> broken.
>

I did do some spot comparisons by using objdump --disassemble on
stage2/<file.o> and <file.o>.  The resulting listings were identical.  If
you remember, however, we did see that xgcc had some differences when built
using the DG assembler.  These went away with the GNU assembler.

> > The program only executes at the assembler level -- no
> source code debugging
> > allowed!  When I switch back to using the DG assembler, dbx
> works fine, but
> > gdb still fails the same way.  Of course, then I'll fail some of the
> > testsuite.  So:  Debugging XOR correct compilation!
>
> I think I'd focus first on using the DG assembler and figuring out the
> deal with GDB.  Only then (when you have a functioning
> debugger) go back
> and add the necessary stuff for --with-gnu-as.
>

It's worth a try.  I'll see what I can do.

> Other than the bootstrap comparison errors (which might be a red
> herring), do you have any reason to think that the native assembler is
> actually bad?
>

I got errors in the following tests:

  gcc.c-torture/compile/981001-2.c
  dg.special/eeprof-1.c

These went away when I switched to GNU as (as well as the compare
succeeding).  They seem to have to do with weak symbols.

> > crti.o was being linked, but objdump --disassemble showed
> nothing in it.
>
> Right.  It is an empty file, meant only to add one symbol.
>

Oh.  Well, I'll try the new crti.o anyway and see if it helps.

> Maybe my standards are just low, but there are a lot of
> people that can
> do a day's work without [cd]tors in dynamic objects and
> debugging info.
>

I'd be a little worried about using a compiler where I couldn't debug the
output.  But, I'll be happy to post whatever I do end up with.  The [cd]tors
worry me less.

   Eric Raskin

Re: DG/UX Port - Giving Up!!

[Robert Lipe]

> > Actually, I doubt that GDB had to know any _debugging_ information to
> > set the breakpoint.  I could have gotten all the info it needed just
> > from the symbol table.
> 
> My assumption was since that gdb knew the source code file and line, that it
> must be able to read something in the debugging info.  Is that in the symbol

OK, good point.   The line number isn't "knowable" without debugging info.
The address of the symbol can be determined via the symbol table but you do
indeed have evidence that it can read at least some of the debugging info.

> I got errors in the following tests:
> 
>   gcc.c-torture/compile/981001-2.c
>   dg.special/eeprof-1.c
> 
> These went away when I switched to GNU as (as well as the compare
> succeeding).  They seem to have to do with weak symbols.

Correct.  I see these failures, too.  This means you have an assembler
that implements weak the way the original designers of weak symbols in
ELF intended.  (There is some debate as to whether or not that's what
they actually *wrote* in the spec, though. :-)

As I remember, these cases try to "retroactively" make a symbol weak
after they've marked it global.

Jeff and I have been working on a patch to cure this.  It isn't unique
to DG/UX.  I think many SVR4-based systems that aren't using GAS will
share these failures.


RJL

Re: DG/UX Port - Giving Up!!

[Jeffrey A Law]

  In message < 078601be9b1a$64c43db0$65c8c8c8@ehrpc.listworks.com >you write:
  > My assumption was since that gdb knew the source code file and line, that
  > it must be able to read something in the debugging info.  Is that in the
  > symbol table?
GDB can get symbols from either the minimal symbol table or from the debug
symbols.

On some platforms it may even be able to get symbols from the dynamic symbol
table, though I've never actually verified if this works.

jeff

Re: DG/UX Port - Giving Up!!

[Jeffrey A Law]

  In message < 19990510104905.D14813@rjlhome.sco.com >you write:
  > It is entirely possible to have the GNU assembler and the native
  > assembler on the same system if that's what you're asking.
Yup.  Lots of systems need to do this.  Including my favorite, hpux :-)


  > If the issue
  > is that you need to GCC to call the two assemblers with different flags,
  > there is prior art for that, too.  (Look in configure.in and search for
  > "sco5gas".  If configured --with-gnu-as that target will forget about
  > all the funky flags to pass to the assembler and instead use a set that
  > will work with GAS.  Note how sco5gas.h just sets a flag and "wraps" the
  > current sco5.h.)
Yup.  We do something similar for hpux too.  Though we don't need to change
the flags, we do need to change certain pseudo-ops and obscure code generation
issues.


  > You may be able to tinker with the debugging formats used.  If you have
  > an all-GNU toolchain (and compatibility with the native chain isn't
  > important), stabs are probably the thing to use.  The way I read dgux.h, 
  > it prefers to use DWARF1 but does also build in stabs.   Try turning that
  > on (using -gstabs) and see if it makes life better for you.  If you like
  > it, then just configure your tree with --with-stabs to make it the default.
Right.  What may be best is to find out what debugging format the existing
tools on the dgux system want to use, then force gcc to use the same kinds of
debug symbols.


  > In general, I found that trying to debug everything (gcc, ld, as, gdb)
  > at once was really hard.  I'd focus on getting the compiler to work well
  > enough to do a bootstrap with native binary tools then iterate over the 
  > debugger and GNU binutils to bring those up.
Right.



jeff

Re: DG/UX Port - Giving Up!!

[Jeffrey A Law]

  > The problem is a little different, I think.  In order to build egcs, I
  > needed to use the GNU assembler.  However, the GNU assembler won't accept
  > the -W,a switches that the DG assembler needs.  So, I guess the right thing
  > to do is to configure egcs to run the assembler and linker from
  > /usr/local/bin and leave /usr/bin alone.  It's not really that I needed to
  > target two assemblers from the same compiler.  It's that I needed to run a
  > different assembler from each compiler.
Easy ;-)

By default egcs will do precisely what you want.  If you configure egcs and
binutils with the same --prefix (or no --prefix option), then egcs will be
able to find the installed GNU assembler before the system assembler.  This
is precisely what we do on hpux.

  > Type "show copying" to see the conditions.
  > There is absolutely no warranty for GDB.  Type "show warranty" for details.
  > This GDB was configured as "i586-dg-dguxR4.20MU03"...
  > (gdb) break main
  > Breakpoint 1 at 0x8048d7a: file goodtest.C, line 34.
  > (gdb) run
  > Starting program: /lw/downloads/mico/bug/goodtest
  > Don't know how to run.  Try "help target".
  > (gdb)
This has nothing to do with the debug symbols.  I would bet that gdb has been
configured to think it is a cross-debugger.  I don't know how that happened,
but the failure you are seeing has nothing to do with the debug symbols.

In fact, the message "Breakpoint 1 at 0x8048d7a: file goodtest.C, line 34."
indicates that gdb was able to find and interpret the debug symbols correctly.



jeff

Re: DG/UX Port - Giving Up!!

[Jeffrey A Law]

  In message < 19990510104905.D14813@rjlhome.sco.com >you write:
  > It is entirely possible to have the GNU assembler and the native
  > assembler on the same system if that's what you're asking.
Yup.  Lots of systems need to do this.  Including my favorite, hpux :-)


  > If the issue
  > is that you need to GCC to call the two assemblers with different flags,
  > there is prior art for that, too.  (Look in configure.in and search for
  > "sco5gas".  If configured --with-gnu-as that target will forget about
  > all the funky flags to pass to the assembler and instead use a set that
  > will work with GAS.  Note how sco5gas.h just sets a flag and "wraps" the
  > current sco5.h.)
Yup.  We do something similar for hpux too.  Though we don't need to change
the flags, we do need to change certain pseudo-ops and obscure code generation
issues.


  > You may be able to tinker with the debugging formats used.  If you have
  > an all-GNU toolchain (and compatibility with the native chain isn't
  > important), stabs are probably the thing to use.  The way I read dgux.h, 
  > it prefers to use DWARF1 but does also build in stabs.   Try turning that
  > on (using -gstabs) and see if it makes life better for you.  If you like
  > it, then just configure your tree with --with-stabs to make it the default.
Right.  What may be best is to find out what debugging format the existing
tools on the dgux system want to use, then force gcc to use the same kinds of
debug symbols.


  > In general, I found that trying to debug everything (gcc, ld, as, gdb)
  > at once was really hard.  I'd focus on getting the compiler to work well
  > enough to do a bootstrap with native binary tools then iterate over the 
  > debugger and GNU binutils to bring those up.
Right.



jeff

Re: DG/UX Port - Giving Up!!

[Robert Lipe]

> > Actually, I doubt that GDB had to know any _debugging_ information to
> > set the breakpoint.  I could have gotten all the info it needed just
> > from the symbol table.
> 
> My assumption was since that gdb knew the source code file and line, that it
> must be able to read something in the debugging info.  Is that in the symbol

OK, good point.   The line number isn't "knowable" without debugging info.
The address of the symbol can be determined via the symbol table but you do
indeed have evidence that it can read at least some of the debugging info.

> I got errors in the following tests:
> 
>   gcc.c-torture/compile/981001-2.c
>   dg.special/eeprof-1.c
> 
> These went away when I switched to GNU as (as well as the compare
> succeeding).  They seem to have to do with weak symbols.

Correct.  I see these failures, too.  This means you have an assembler
that implements weak the way the original designers of weak symbols in
ELF intended.  (There is some debate as to whether or not that's what
they actually *wrote* in the spec, though. :-)

As I remember, these cases try to "retroactively" make a symbol weak
after they've marked it global.

Jeff and I have been working on a patch to cure this.  It isn't unique
to DG/UX.  I think many SVR4-based systems that aren't using GAS will
share these failures.


RJL

RE: DG/UX Port - Giving Up!!

[Eric Raskin]

Robert:

 Thanks for the reply...

>
> It is entirely possible to have the GNU assembler and the native
> assembler on the same system if that's what you're asking.
> If the issue
> is that you need to GCC to call the two assemblers with
> different flags,
> there is prior art for that, too.  (Look in configure.in and
> search for
> "sco5gas".  If configured --with-gnu-as that target will forget about
> all the funky flags to pass to the assembler and instead use
> a set that
> will work with GAS.  Note how sco5gas.h just sets a flag and
> "wraps" the
> current sco5.h.)

The problem is a little different, I think.  In order to build egcs, I
needed to use the GNU assembler.  However, the GNU assembler won't accept
the -W,a switches that the DG assembler needs.  So, I guess the right thing
to do is to configure egcs to run the assembler and linker from
/usr/local/bin and leave /usr/bin alone.  It's not really that I needed to
target two assemblers from the same compiler.  It's that I needed to run a
different assembler from each compiler.

> You may be able to tinker with the debugging formats used.
> If you have
> an all-GNU toolchain (and compatibility with the native chain isn't
> important), stabs are probably the thing to use.  The way I
> read dgux.h,
> it prefers to use DWARF1 but does also build in stabs.   Try
> turning that
> on (using -gstabs) and see if it makes life better for you.
> If you like
> it, then just configure your tree with --with-stabs to make
> it the default.
>

I just tried your suggestion.  No change.  I get the following from gdb when
I try to execute a program that works properly.

$ eg++ -gstabs -o goodtest goodtest.C

$ gdb goodtest
$ GNU gdb 4.18
Copyright 1998 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 "i586-dg-dguxR4.20MU03"...
(gdb) break main
Breakpoint 1 at 0x8048d7a: file goodtest.C, line 34.
(gdb) run
Starting program: /lw/downloads/mico/bug/goodtest
Don't know how to run.  Try "help target".
(gdb)

As you can see, gdb seems to be able to read some of the debugging
information (witness the breakpoint), but it can't run the file.  How
strange!  When I try to use dbx instead, I get:

$ dbx goodtest
Type "help" for a list of commands
Processing object: /lw/downloads/mico/bug/goodtest
Updating linker symbol table...641 symbols added. (Total: 641)
Updating symbolic debugging information...0 modules added. (Total: 0)
Processing object: /usr/dglib/libc.so.1
Updating linker symbol table...1768 symbols added. (Total: 2409)
Updating symbolic debugging information...0 modules added. (Total: 0)
(dbx) stop in main
(0) stop in main
(dbx) run
Starting program: /lw/downloads/mico/bug/goodtest

In Global Constructor
(0) Stopped at pc 0x8048d74 (main)
*       0x8048d74 main  pushl   %ebp
(dbx)

The program only executes at the assembler level -- no source code debugging
allowed!  When I switch back to using the DG assembler, dbx works fine, but
gdb still fails the same way.  Of course, then I'll fail some of the
testsuite.  So:  Debugging XOR correct compilation!

> In general, I found that trying to debug everything (gcc, ld, as, gdb)
> at once was really hard.  I'd focus on getting the compiler
> to work well
> enough to do a bootstrap with native binary tools then
> iterate over the
> debugger and GNU binutils to bring those up.
>

I had to do this in reverse, since I couldn't get a clean egcs build with
the native assembler -- the stage2-to-stage3 compare fails.  This compare
succeeds and all the libraries build properly when I switch to GNU
assembler.  So, I have to build the binutils first, then the compiler.  Note
that I **do** have a successful compiler build, just without debugging!

> > Finally, I've found that the egcs C++ implementation on DG/UX won't
> > call global constructors/destructors from shared libraries.  It
> > isn't just dynamic linking using dlopen(), it's even the DG/UX
> > version of ld.so that won't do it.  On DG/UX, this file is called
> > /usr/dglib/libc.so.1, for anyone who cares to take a look at it.
>
> We had (and fixed!) this very problem in OpenServer just before 1.1.2
> went out.  Look in the Feb egcs-bugs archives for the threads:
>
> 	Final patch for shared library problem in SCO OpenServer
> 	shared library patch for SCO OpenServer 5.0.5 & egcs
>
> If yours is an ELF-based SVR4-ish systems (and I think it is)
> you might
> find this to be pertinent.
>

crti.o was being linked, but objdump --disassemble showed nothing in it.
I'm rebuilding with similar patches to the SCO platform (getting crti.o
built), which I'll manually install in place of the crti.o on my ssytem.
I'll let you know if it helps.

> It may be as simple as ensuring that crti.o abd crtn.o get linked in
> the right places if your system provides these.
>
> > So, I'm giving up on this port.  It's now beyond my abilities.
>
> It doesn't sound like you're that far from the finish line, really.
>

Funny -- it seems a million miles away ! :-)

>
> RJL
>

DG/UX Port - Giving Up!!

[Eric Raskin]

Bad news for the two or three DG/UX people out there.... :-(

I'm giving up on the DG/UX Intel port of egcs (i586-dg-dguxR4.20MU03).  In
order to make everything work, you need to switch from the DG/UX assembler
and linker to the GNU versions.  If you don't, then the "weak" designations
don't work properly, and the stage2-to-stage3 compare operation during the
bootstrap fails.  If you do change, then you break the compiler supplied
with the base OS (which specifies some funky switches to the DG assembler in
order to fix up debugging information).  I've also found that debugging with
the new tools is completely broken -- I can't get dbx or gdb to debug
anything produced by the GNU assember/linker tools.  As a matter of fact, I
can't even get the objcopy utility to copy an ELF executable properly when
produced by any of the three compilers on my system -- gcc 2.7.2 (base OS),
gcc 2.8.1 (built myself) and egcs 19990502 snapshot.  The debugging info
gets trashed.  (I'm using binutils 2.9.1.)

Finally, I've found that the egcs C++ implementation on DG/UX won't call
global constructors/destructors from shared libraries.  It isn't just
dynamic linking using dlopen(), it's even the DG/UX version of ld.so that
won't do it.  On DG/UX, this file is called /usr/dglib/libc.so.1, for anyone
who cares to take a look at it.

So, I'm giving up on this port.  It's now beyond my abilities.  Anyone who
wishes to take it over from me can send an E-Mail to ehr@listworks.com.
I'll be happy to send along all the patches I've developed so far.
Alternatively, if anyone has any advice or quick fixes, I'll be happy to try
again.

----------------------------------------------------------------------------
----------------
Eric H. Raskin                                 Voice: 914-769-7100 x321
President, CSC Division                   Fax:    914-769-8070
The Listworks Corp.                         E-Mail: ehr@listworks.com
1 Campus Drive
Pleasantville, NY 10570

PS.  I spoke to the people at Data General.  They only support a C++
compiler sold by EPC (Edinburgh Portable Compilers).  I guess I'll have to
go buy it.  Anyone know anything about it?

Re: DG/UX Port - Giving Up!!

[Jeffrey A Law]

  > The problem is a little different, I think.  In order to build egcs, I
  > needed to use the GNU assembler.  However, the GNU assembler won't accept
  > the -W,a switches that the DG assembler needs.  So, I guess the right thing
  > to do is to configure egcs to run the assembler and linker from
  > /usr/local/bin and leave /usr/bin alone.  It's not really that I needed to
  > target two assemblers from the same compiler.  It's that I needed to run a
  > different assembler from each compiler.
Easy ;-)

By default egcs will do precisely what you want.  If you configure egcs and
binutils with the same --prefix (or no --prefix option), then egcs will be
able to find the installed GNU assembler before the system assembler.  This
is precisely what we do on hpux.

  > Type "show copying" to see the conditions.
  > There is absolutely no warranty for GDB.  Type "show warranty" for details.
  > This GDB was configured as "i586-dg-dguxR4.20MU03"...
  > (gdb) break main
  > Breakpoint 1 at 0x8048d7a: file goodtest.C, line 34.
  > (gdb) run
  > Starting program: /lw/downloads/mico/bug/goodtest
  > Don't know how to run.  Try "help target".
  > (gdb)
This has nothing to do with the debug symbols.  I would bet that gdb has been
configured to think it is a cross-debugger.  I don't know how that happened,
but the failure you are seeing has nothing to do with the debug symbols.

In fact, the message "Breakpoint 1 at 0x8048d7a: file goodtest.C, line 34."
indicates that gdb was able to find and interpret the debug symbols correctly.



jeff

RE: DG/UX Port - Giving Up!!

[Eric Raskin]

>
> Actually, I doubt that GDB had to know any _debugging_ information to
> set the breakpoint.  I could have gotten all the info it needed just
> from the symbol table.
>

My assumption was since that gdb knew the source code file and line, that it
must be able to read something in the debugging info.  Is that in the symbol
table?

> As for GDB not knowing how to run the binary in question, that's
> orthogonal to the debugging info.  GDB can run programs with _no_
> debugging info (or even symbol tables) so that is a different issue.
>

OK -- I'll have to look into that.

> My guess is that somewhere somehow, the resulting object file is
> slightly different in something like an OS version stamp.  Perhaps
> comparing the output from the two files via a gdb 'info file' is in
> order.  Be sure, too, that GDB can debug programs that aren't built by
> this chain at all - it sounds entirely possible that your GDB is just
> broken.
>

I did do some spot comparisons by using objdump --disassemble on
stage2/<file.o> and <file.o>.  The resulting listings were identical.  If
you remember, however, we did see that xgcc had some differences when built
using the DG assembler.  These went away with the GNU assembler.

> > The program only executes at the assembler level -- no
> source code debugging
> > allowed!  When I switch back to using the DG assembler, dbx
> works fine, but
> > gdb still fails the same way.  Of course, then I'll fail some of the
> > testsuite.  So:  Debugging XOR correct compilation!
>
> I think I'd focus first on using the DG assembler and figuring out the
> deal with GDB.  Only then (when you have a functioning
> debugger) go back
> and add the necessary stuff for --with-gnu-as.
>

It's worth a try.  I'll see what I can do.

> Other than the bootstrap comparison errors (which might be a red
> herring), do you have any reason to think that the native assembler is
> actually bad?
>

I got errors in the following tests:

  gcc.c-torture/compile/981001-2.c
  dg.special/eeprof-1.c

These went away when I switched to GNU as (as well as the compare
succeeding).  They seem to have to do with weak symbols.

> > crti.o was being linked, but objdump --disassemble showed
> nothing in it.
>
> Right.  It is an empty file, meant only to add one symbol.
>

Oh.  Well, I'll try the new crti.o anyway and see if it helps.

> Maybe my standards are just low, but there are a lot of
> people that can
> do a day's work without [cd]tors in dynamic objects and
> debugging info.
>

I'd be a little worried about using a compiler where I couldn't debug the
output.  But, I'll be happy to post whatever I do end up with.  The [cd]tors
worry me less.

   Eric Raskin

Re: DG/UX Port - Giving Up!!

[Jeffrey A Law]

  In message < 078601be9b1a$64c43db0$65c8c8c8@ehrpc.listworks.com >you write:
  > My assumption was since that gdb knew the source code file and line, that
  > it must be able to read something in the debugging info.  Is that in the
  > symbol table?
GDB can get symbols from either the minimal symbol table or from the debug
symbols.

On some platforms it may even be able to get symbols from the dynamic symbol
table, though I've never actually verified if this works.

jeff

Re: DG/UX Port - Giving Up!!

[Robert Lipe]

I've never seen DG/UX, but some of these sound familiar to me.

Eric Raskin wrote:

> I'm giving up on the DG/UX Intel port of egcs (i586-dg-dguxR4.20MU03).
> In order to make everything work, you need to switch from the DG/UX
> assembler and linker to the GNU versions.  If you don't, then the
> "weak" designations don't work properly, and the stage2-to-stage3
> compare operation during the bootstrap fails.  If you do change, then
> you break the compiler supplied with the base OS (which specifies
> some funky switches to the DG assembler in order to fix up debugging
> information).

It is entirely possible to have the GNU assembler and the native
assembler on the same system if that's what you're asking.  If the issue
is that you need to GCC to call the two assemblers with different flags,
there is prior art for that, too.  (Look in configure.in and search for
"sco5gas".  If configured --with-gnu-as that target will forget about
all the funky flags to pass to the assembler and instead use a set that
will work with GAS.  Note how sco5gas.h just sets a flag and "wraps" the
current sco5.h.)

> I've also found that debugging with the new tools is completely
> broken -- I can't get dbx or gdb to debug anything produced by the
> GNU assember/linker tools.  As a matter of fact, I can't even get the
> objcopy utility to copy an ELF executable properly when produced by
> any of the three compilers on my system -- gcc 2.7.2 (base OS), gcc
> 2.8.1 (built myself) and egcs 19990502 snapshot.  The debugging info
> gets trashed.  (I'm using binutils 2.9.1.)

You may be able to tinker with the debugging formats used.  If you have
an all-GNU toolchain (and compatibility with the native chain isn't
important), stabs are probably the thing to use.  The way I read dgux.h, 
it prefers to use DWARF1 but does also build in stabs.   Try turning that
on (using -gstabs) and see if it makes life better for you.  If you like
it, then just configure your tree with --with-stabs to make it the default.

In general, I found that trying to debug everything (gcc, ld, as, gdb)
at once was really hard.  I'd focus on getting the compiler to work well
enough to do a bootstrap with native binary tools then iterate over the 
debugger and GNU binutils to bring those up.

Of course, there are those on the list that scoff at such things since
they're so studly as to be able to effectively debug all those things in
parallel while using an system with bad RAMs. :-)


> Finally, I've found that the egcs C++ implementation on DG/UX won't
> call global constructors/destructors from shared libraries.  It
> isn't just dynamic linking using dlopen(), it's even the DG/UX
> version of ld.so that won't do it.  On DG/UX, this file is called
> /usr/dglib/libc.so.1, for anyone who cares to take a look at it.

We had (and fixed!) this very problem in OpenServer just before 1.1.2
went out.  Look in the Feb egcs-bugs archives for the threads:

	Final patch for shared library problem in SCO OpenServer
	shared library patch for SCO OpenServer 5.0.5 & egcs

If yours is an ELF-based SVR4-ish systems (and I think it is) you might
find this to be pertinent.

It may be as simple as ensuring that crti.o abd crtn.o get linked in
the right places if your system provides these.

> So, I'm giving up on this port.  It's now beyond my abilities.

It doesn't sound like you're that far from the finish line, really.


RJL

Re: DG/UX Port - Giving Up!!

[Robert Lipe]

> The problem is a little different, I think.  In order to build egcs,
> I needed to use the GNU assembler.  However, the GNU assembler won't
> accept the -W,a switches that the DG assembler needs.  So, I guess the
> right thing to do is to configure egcs to run the assembler and linker
> from /usr/local/bin and leave /usr/bin alone.  It's not really that I
> needed to target two assemblers from the same compiler.  It's that I
> needed to run a different assembler from each compiler.

That's what I was suggesting.

It's possible to have different EGCS installations each using different
assemblers.  If you combine this with the idea of actually *telling*
dgux.h about this, you can easily wire it to use /bin/as with DGUX-ish
switchs and (via --with-gnu-as) to use some other assembler with
different flags.


> (gdb) run
> Starting program: /lw/downloads/mico/bug/goodtest
> Don't know how to run.  Try "help target".
> (gdb)
> 
> As you can see, gdb seems to be able to read some of the debugging
> information (witness the breakpoint), but it can't run the file.  

Actually, I doubt that GDB had to know any _debugging_ information to
set the breakpoint.  I could have gotten all the info it needed just
from the symbol table.

As for GDB not knowing how to run the binary in question, that's
orthogonal to the debugging info.  GDB can run programs with _no_
debugging info (or even symbol tables) so that is a different issue.

My guess is that somewhere somehow, the resulting object file is
slightly different in something like an OS version stamp.  Perhaps
comparing the output from the two files via a gdb 'info file' is in
order.  Be sure, too, that GDB can debug programs that aren't built by
this chain at all - it sounds entirely possible that your GDB is just
broken.

> The program only executes at the assembler level -- no source code debugging
> allowed!  When I switch back to using the DG assembler, dbx works fine, but
> gdb still fails the same way.  Of course, then I'll fail some of the
> testsuite.  So:  Debugging XOR correct compilation!

I think I'd focus first on using the DG assembler and figuring out the
deal with GDB.  Only then (when you have a functioning debugger) go back
and add the necessary stuff for --with-gnu-as.

Other than the bootstrap comparison errors (which might be a red
herring), do you have any reason to think that the native assembler is
actually bad?

> crti.o was being linked, but objdump --disassemble showed nothing in it.

Right.  It is an empty file, meant only to add one symbol.

> > It doesn't sound like you're that far from the finish line, really.
> Funny -- it seems a million miles away ! :-)

Maybe my standards are just low, but there are a lot of people that can
do a day's work without [cd]tors in dynamic objects and debugging info.

If you're getting executables out of it that work (and you must be if
you're even making it to the third stage) I suggest there is value in
your work.

RJL