GDB on SGI Irix 6.5

GDB on SGI Irix 6.5

[Eli Zaretskii]

Did someone successfully build the current CVS version on Irix 6.5?  If 
so, are there any special tricks one need to be aware of to do that?

I built GDB with "./configure; make" with the native C compiler and a 
native Make.  While it built okay, the resulting binary aborts at runtime 
like this:

  (src)gdb ./emacs
  GNU gdb 20010402
  Copyright 2001 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 "mips-sgi-irix6.5"...
  Environment variable "DISPLAY" not defined.
  TERM = vt220
  Breakpoint 1 at 0x100ff7d0: file emacs.c, line 384.
  Breakpoint 2 at 0x100d8e18: file xterm.c, line 11714.
  (gdb) b main
  Breakpoint 3 at 0x100ffe48: file emacs.c, line 736.
  (gdb) r -q
  Starting program: /gnu/emacs-21/emacs-21.0.101/src/./emacs -q
  regcache.c:282: gdb-internal-error: Assertion `regnum >= 0 && regnum < (NUM_REGS + NUM_PSEUDO_REGS)' failed.
  An internal GDB error was detected.  This may make further
  debugging unreliable.  Continue this debugging session? (y or n)

I've verified that this happens because legacy_read_register_gen is 
called with regnum = 72, while it doesn't expect any register to have a 
number greater than 71.

Any clues?

Re: GDB on SGI Irix 6.5

[Daniel Berlin]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Did someone successfully build the current CVS version on Irix 6.5?  If 
> so, are there any special tricks one need to be aware of to do that?
> 
> I built GDB with "./configure; make" with the native C compiler and a 
> native Make.  While it built okay, the resulting binary aborts at runtime 
> like this:
> 
>   (src)gdb ./emacs
>   GNU gdb 20010402
>   Copyright 2001 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 "mips-sgi-irix6.5"...
>   Environment variable "DISPLAY" not defined.
>   TERM = vt220
>   Breakpoint 1 at 0x100ff7d0: file emacs.c, line 384.
>   Breakpoint 2 at 0x100d8e18: file xterm.c, line 11714.
>   (gdb) b main
>   Breakpoint 3 at 0x100ffe48: file emacs.c, line 736.
>   (gdb) r -q
>   Starting program: /gnu/emacs-21/emacs-21.0.101/src/./emacs -q
>   regcache.c:282: gdb-internal-error: Assertion `regnum >= 0 && regnum < (NUM_REGS + NUM_PSEUDO_REGS)' failed.
>   An internal GDB error was detected.  This may make further
>   debugging unreliable.  Continue this debugging session? (y or n)
> 
> I've verified that this happens because legacy_read_register_gen is 
> called with regnum = 72, while it doesn't expect any register to have a 
> number greater than 71.
> 
> Any clues?

This type of thing has been happening on IRIX for at least a year.
I remember getting a similar problem when I had an SGI machine for a
few months last year.


-- 
When I was little, my grandfather used to make me stand in a
closet for five minutes without moving.  He said it was elevator
practice.

Re: GDB on SGI Irix 6.5

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> Did someone successfully build the current CVS version on Irix 6.5?  If
> so, are there any special tricks one need to be aware of to do that?
> 
> I built GDB with "./configure; make" with the native C compiler and a
> native Make.  While it built okay, the resulting binary aborts at runtime
> like this:

Hmm, I've this sinking feeling that, prior to me adding the assert() it
was falling off the end of the regcache and just blatting memory :-/

72, I've this feeling that it is the ``FP'':

ac131313@localhost$ grep 72 config/mips/tm-*
config/mips/tm-mips.h:#define FP_REGNUM 72              /* Pseudo
register that contains true address of executing stack frame */

As a quick hack, pump up NUM_PSEUDO_REGS to make space for this (and
possibly a few more).

As a correct fix (ie don't try this at home :-). You could consider
eliminating read_fp(), write_fp() and FP_REGNUM so that targets that
didn't have a real FP register got the value from ``struct frame *''.

	Andrew

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

On Tue, 17 Apr 2001, Andrew Cagney wrote:

> Hmm, I've this sinking feeling that, prior to me adding the assert() it
> was falling off the end of the regcache and just blatting memory :-/
> 
> 72, I've this feeling that it is the ``FP'':
> 
> ac131313@localhost$ grep 72 config/mips/tm-*
> config/mips/tm-mips.h:#define FP_REGNUM 72              /* Pseudo
> register that contains true address of executing stack frame */
> 
> As a quick hack, pump up NUM_PSEUDO_REGS to make space for this (and
> possibly a few more).

Thanks for the hint.

However, this doesn't work: it again bumps into internal_error because 
there's no gdbarch method for fetching pseudo registers.  How would such 
a method look for a target that doesn't have a frame pointer?

Also, strangely enough, tm-irix3.h does define a place for FP in the 
registers array (at index 30).  So why doesn't it define FP_REGNUM 
accordingly?

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

> Date: Wed, 18 Apr 2001 19:31:42 +0300 (IDT)
> From: Eli Zaretskii <eliz@is.elta.co.il>
> 
> On Tue, 17 Apr 2001, Andrew Cagney wrote:
> 
> > Hmm, I've this sinking feeling that, prior to me adding the assert() it
> > was falling off the end of the regcache and just blatting memory :-/
> > 
> > 72, I've this feeling that it is the ``FP'':
> > 
> > ac131313@localhost$ grep 72 config/mips/tm-*
> > config/mips/tm-mips.h:#define FP_REGNUM 72              /* Pseudo
> > register that contains true address of executing stack frame */
> > 
> > As a quick hack, pump up NUM_PSEUDO_REGS to make space for this (and
> > possibly a few more).
> 
> Thanks for the hint.
> 
> However, this doesn't work: it again bumps into internal_error because 
> there's no gdbarch method for fetching pseudo registers.  How would such 
> a method look for a target that doesn't have a frame pointer?
> 
> Also, strangely enough, tm-irix3.h does define a place for FP in the 
> registers array (at index 30).  So why doesn't it define FP_REGNUM 
> accordingly?

I think I've got it: tm-irix3.h is simply wrong for either Irix 6.5 or
the N32 ABI and the MIPS CPUs that support it (or both).  Not only
should FP_REGNUM be set to 30, but the enumeration and the total
number of registers defined on tm-irix3.h is incorrect for the SGI
machine I have here.

tm-mips.h, which defines FP_REGNUM to 72, is also wrong for Irix, at
least for Irix 6.5 with N32 executables.  I have no idea how could
this possibly work for anyone in the past.

I have a provisional patch which seems to DTRT for me.  But to clean
it up (so that I can submit it without blushing ;-), I need help in
making several decisions, since I have no prior experience with, or
knowledge about, the different CPUs and ABIs supported by SGI Irix.

Questions:

  - Should I make the change in tm-irix5.h, or should I leave it alone
    and create irix6x.h?  The issue here is that perhaps Irix 5 did
    work like tm-irix5.h says, and I won't want to break that.

  - What should I do about the different ABIs?  At least 3 come to
    mind: O32, N32, and N64.  They have subtly different layouts of
    registers, so if I need to set things up for more than a single
    ABI, I'll need to know what's the current say-so about how this
    should be done (e.g., does gdbarch has some functionality for
    dynamically computing the registers array?).

Thanks in advance for any help.

Re: GDB on SGI Irix 6.5

[Andrew Cagney]

>   - Should I make the change in tm-irix5.h, or should I leave it alone
>     and create irix6x.h?  The issue here is that perhaps Irix 5 did
>     work like tm-irix5.h says, and I won't want to break that.

I think everyone has agreed on tm-irix6.h.

>   - What should I do about the different ABIs?  At least 3 come to
>     mind: O32, N32, and N64.  They have subtly different layouts of
>     registers, so if I need to set things up for more than a single
>     ABI, I'll need to know what's the current say-so about how this
>     should be done (e.g., does gdbarch has some functionality for
>     dynamically computing the registers array?).

By subtle differences in registers do you mean the register use or
layout?

mips-tdep.c:mips_gdbarch_init() is hopefully already detecting the ABI
and setting things up to handle the register usage differences.

With regard to register layout, the MIPS still, unfortunatly, uses a
static configuration.  multi-arch can support dynamic register layouts,
it is just not implemented for MIPS.

	Andrew

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

> Date: Mon, 30 Apr 2001 13:01:33 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> >   - Should I make the change in tm-irix5.h, or should I leave it alone
> >     and create irix6x.h?  The issue here is that perhaps Irix 5 did
> >     work like tm-irix5.h says, and I won't want to break that.
> 
> I think everyone has agreed on tm-irix6.h.

Yes; tm-irix6.h it is.

> >   - What should I do about the different ABIs?  At least 3 come to
> >     mind: O32, N32, and N64.  They have subtly different layouts of
> >     registers, so if I need to set things up for more than a single
> >     ABI, I'll need to know what's the current say-so about how this
> >     should be done (e.g., does gdbarch has some functionality for
> >     dynamically computing the registers array?).
> 
> By subtle differences in registers do you mean the register use or
> layout?

The names of some registers are different, and some of the registers
defined by tm-irix3.h and used by tm-irix5.h, evidently for O32 and
older ABIs, don't exist in N32 and 64, according to my references.

> mips-tdep.c:mips_gdbarch_init() is hopefully already detecting the ABI
> and setting things up to handle the register usage differences.

Not really.  I discovered that tm-irix3.h and tm-irix5.h are totally
wrong for N32 (that's why GDB crashed for me).  In particular, they
define FP_REGNUM incorrectly.

> With regard to register layout, the MIPS still, unfortunatly, uses a
> static configuration.  multi-arch can support dynamic register layouts,
> it is just not implemented for MIPS.

I'll try to make tm-irix6.h do a better job (no promises ;-).

Thanks for the feedback.

Re: GDB on SGI Irix 6.5

[Jim Blandy]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> On 13 Jun 2001, Jim Blandy wrote:
> > assuming we've decided a .debug_info section is carrying SGI 64-bit
> > Dwarf2 data, has someone already adapted dwarf2read to read the
> > data?
> 
> There's a patch on Dave's site which is supposed to do that.  That
> patch is against GDB 4.17, and is based on compile-time #ifdef's, but
> otherwise it should be fine.

Yeah.  The #ifdefs must go (you knew I was going to say that) before
we can incorporate the change.

Re: GDB on SGI Irix 6.5

[Daniel Berlin]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On 13 Jun 2001, Jim Blandy wrote:
> 
>> assuming we've decided a .debug_info section is carrying SGI 64-bit
>> Dwarf2 data, has someone already adapted dwarf2read to read the
>> data?
> 
> There's a patch on Dave's site which is supposed to do that.  That
> patch is against GDB 4.17, and is based on compile-time #ifdef's, but
> otherwise it should be fine.
> 
> What I was trying to figure out was how to add this support in a
> cleaner way, so that Irix 6.x users will not need two different GDB
> binaries to debug programs, one each for each ABI.

You can check if the initial length is 0, followed by a valid number
(IE not zero).
If so, either we've got completely invalid dwarf2, or SGI's 64bit
dwarf2.



-- 
"It doesn't matter what temperature the room is, it's always room
temperature.
"-Steven Wright

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

On 13 Jun 2001, Jim Blandy wrote:

> assuming we've decided a .debug_info section is carrying SGI 64-bit
> Dwarf2 data, has someone already adapted dwarf2read to read the
> data?

There's a patch on Dave's site which is supposed to do that.  That
patch is against GDB 4.17, and is based on compile-time #ifdef's, but
otherwise it should be fine.

What I was trying to figure out was how to add this support in a
cleaner way, so that Irix 6.x users will not need two different GDB
binaries to debug programs, one each for each ABI.

Re: GDB on SGI Irix 6.5

[Daniel Berlin]

David B Anderson <davea@quasar.engr.sgi.com> writes:

>|
>|> From: Elena Zannoni <ezannoni@cygnus.com>
>|> Date: Tue, 12 Jun 2001 16:03:49 -0400
>|> 
>|> Andrew Cagney writes:
>|>  > [I'll take the liberty of adding Elena and Jim.  Might be useful to pose 
>|>  > any follow on questions on gdb@]
>|>  > 
>|>  > > On Thu, 17 May 2001, David B Anderson wrote:
>|>  > > 
>|>  > > 
>|>  > >> The 64bit dwarf2 that is read by read_initial_length is based on
>|>  > >> dwarf 2.1, designed in 2000.  SGI 64bit dwarf2 was designed in
>|>  > >> the early 1990's.  SGI made offsets etc 64bit in elf64
>|>  > >> (and offsets etc 32bits in elf32).    
>|>  > >> (basically we could not bring ourselves to limit dwarf 
>|>  > >> offsets to 32 bits in an elf64 file...)
>|>  > >> 
>|>  > >> Anyway,  to be correct for IRIX6,  read_initial_length
>|>  > >> needs to know it is IRIX elf64 and then
>|>  > >> /* UNTESTED, NOT ALL THAT NEEDS TO BE DONE probably */
>|>  > >> cu_header->initial_length_size = 8;
>|>  > >> cu_header->offset_size = 8;
>|>  > >> at least gives the right sizes.
>|>  > > 
>|>  > > 
>|> 
>|> Are these the only differences? Is anything SGI specific encoded in the
>|> 'version' field of cu_header? Maybe that can be used. Is there somewhere 
>|> in the debug info a field that tells that this is SGI's version?
>|
>|I don't see anything in the documents I got from Dave's site.  Dave,
>|could you please answer these questions?
>|
>|Thanks for the other advice, I will look that up.
> 
> Hopefully already anwered. No, other field in dwarf2.
> 
> However, because IRIX is big-endian, and because no
> compilation unit should have an
> 	initial-length
> field with all zero bits,
> 
> A test for a dwarf2 CU (compilation unit) 
> initial-length of zero followed 4 bytes
> later by a correct version number for dwarf2
> might suffice (in an elf64 big endian object) folowed by setting
> up the initial_length_size and offset_size 
> as above might suffice.

This is correct.  The initial length should never be zero.  Even for
64 bit dwarf 2.1, it's 0xffffffff followed by 8 bytes of the real
initial length.


> 
> Whether this can be done sensibly multi-arch in gdb is not clear to me.
> 
> davea@sgi.com

-- 
"How young can you die of old age?
"-Steven Wright

Re: GDB on SGI Irix 6.5

[David B Anderson]

|
|> From: Elena Zannoni <ezannoni@cygnus.com>
|> Date: Tue, 12 Jun 2001 16:03:49 -0400
|> 
|> Andrew Cagney writes:
|>  > [I'll take the liberty of adding Elena and Jim.  Might be useful to pose 
|>  > any follow on questions on gdb@]
|>  > 
|>  > > On Thu, 17 May 2001, David B Anderson wrote:
|>  > > 
|>  > > 
|>  > >> The 64bit dwarf2 that is read by read_initial_length is based on
|>  > >> dwarf 2.1, designed in 2000.  SGI 64bit dwarf2 was designed in
|>  > >> the early 1990's.  SGI made offsets etc 64bit in elf64
|>  > >> (and offsets etc 32bits in elf32).    
|>  > >> (basically we could not bring ourselves to limit dwarf 
|>  > >> offsets to 32 bits in an elf64 file...)
|>  > >> 
|>  > >> Anyway,  to be correct for IRIX6,  read_initial_length
|>  > >> needs to know it is IRIX elf64 and then
|>  > >> /* UNTESTED, NOT ALL THAT NEEDS TO BE DONE probably */
|>  > >> cu_header->initial_length_size = 8;
|>  > >> cu_header->offset_size = 8;
|>  > >> at least gives the right sizes.
|>  > > 
|>  > > 
|> 
|> Are these the only differences? Is anything SGI specific encoded in the
|> 'version' field of cu_header? Maybe that can be used. Is there somewhere 
|> in the debug info a field that tells that this is SGI's version?
|
|I don't see anything in the documents I got from Dave's site.  Dave,
|could you please answer these questions?
|
|Thanks for the other advice, I will look that up.

Hopefully already anwered. No, other field in dwarf2.

However, because IRIX is big-endian, and because no
compilation unit should have an
	initial-length
field with all zero bits,

A test for a dwarf2 CU (compilation unit) 
initial-length of zero followed 4 bytes
later by a correct version number for dwarf2
might suffice (in an elf64 big endian object) folowed by setting
up the initial_length_size and offset_size 
as above might suffice.

Whether this can be done sensibly multi-arch in gdb is not clear to me.

davea@sgi.com

Re: GDB on SGI Irix 6.5

[Andrew Cagney]

> So you are saying that there's nothing in the file--not a single
> thing--that would allow GDB to find out if the debug info is for 64 or
> n32 ABI?
> 
> Would it be reasonable then to try one format, and if that fails, try
> the other?  (I know that it fails somewhere, because when I try to
> debug a 64-bit executable with GDB built from current CVS, it
> complains about something like ``wrong version'' (IIRC).)


There must be something.  What does `file foo` do?

  Have a peak at the magic numbers.  See: mips-tdep.c:mips_gdbarch_init():


  /* Extract the elf_flags if available */
  if (info.abfd != NULL
      && bfd_get_flavour (info.abfd) == bfd_target_elf_flavour)
    elf_flags = elf_elfheader (info.abfd)->e_flags;
  else
    elf_flags = 0;

  /* Check ELF_FLAGS to see if it specifies the ABI being used. */
  switch ((elf_flags & EF_MIPS_ABI))
    {
 

Andrew

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

> Date: Wed, 13 Jun 2001 09:50:09 -0700 (PDT)
> From: David B Anderson <davea@quasar.engr.sgi.com>
> 
> The irix 64 dwarf2 debug info is identical 
> to what dwarf2read.c reads (and only dwarf2read, not anything else)
> except for the initial bytes of CU being 8 bytes, not 12
> (see dwarf2read) and the determination of offset and length
> size being based on 'IRIX6.5' not on internal evidence in the dwarf
> itself.

So you are saying that there's nothing in the file--not a single
thing--that would allow GDB to find out if the debug info is for 64 or
n32 ABI?

Would it be reasonable then to try one format, and if that fails, try
the other?  (I know that it fails somewhere, because when I try to
debug a 64-bit executable with GDB built from current CVS, it
complains about something like ``wrong version'' (IIRC).)

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

> From: Elena Zannoni <ezannoni@cygnus.com>
> Date: Tue, 12 Jun 2001 16:03:49 -0400
> 
> Andrew Cagney writes:
>  > [I'll take the liberty of adding Elena and Jim.  Might be useful to pose 
>  > any follow on questions on gdb@]
>  > 
>  > > On Thu, 17 May 2001, David B Anderson wrote:
>  > > 
>  > > 
>  > >> The 64bit dwarf2 that is read by read_initial_length is based on
>  > >> dwarf 2.1, designed in 2000.  SGI 64bit dwarf2 was designed in
>  > >> the early 1990's.  SGI made offsets etc 64bit in elf64
>  > >> (and offsets etc 32bits in elf32).    
>  > >> (basically we could not bring ourselves to limit dwarf 
>  > >> offsets to 32 bits in an elf64 file...)
>  > >> 
>  > >> Anyway,  to be correct for IRIX6,  read_initial_length
>  > >> needs to know it is IRIX elf64 and then
>  > >> /* UNTESTED, NOT ALL THAT NEEDS TO BE DONE probably */
>  > >> cu_header->initial_length_size = 8;
>  > >> cu_header->offset_size = 8;
>  > >> at least gives the right sizes.
>  > > 
>  > > 
> 
> Are these the only differences? Is anything SGI specific encoded in the
> 'version' field of cu_header? Maybe that can be used. Is there somewhere 
> in the debug info a field that tells that this is SGI's version?

I don't see anything in the documents I got from Dave's site.  Dave,
could you please answer these questions?

Thanks for the other advice, I will look that up.

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

I'm forwarding this to the list per Andrew's suggestion, to give people 
background when they read the followups.

---------- Forwarded message ----------
Date: Tue, 12 Jun 2001 15:43:00 +0300 (IDT)
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: David B Anderson <davea@quasar.engr.sgi.com>
Subject: Re: GDB on SGI Irix 6.5


On Thu, 17 May 2001, David B Anderson wrote:

> The 64bit dwarf2 that is read by read_initial_length is based on
> dwarf 2.1, designed in 2000.  SGI 64bit dwarf2 was designed in
> the early 1990's.  SGI made offsets etc 64bit in elf64
> (and offsets etc 32bits in elf32).    
> (basically we could not bring ourselves to limit dwarf 
> offsets to 32 bits in an elf64 file...)
> 
> Anyway,  to be correct for IRIX6,  read_initial_length
> needs to know it is IRIX elf64 and then
> 	 /* UNTESTED, NOT ALL THAT NEEDS TO BE DONE probably */
>          cu_header->initial_length_size = 8;
>          cu_header->offset_size = 8;
> at least gives the right sizes.

Andrew, I think I need your help to decide how to go about adding support 
for the debugging SGI 64-bit executables, since my understanding of 
multi-arch is still almost nonexistent.

First, it is not clear to me whether the issue of SGI's n32 vs 64 ABI is
at all consistent with the design of GDB's mult-arch facilities.  We are 
talking about two ABIs which are almost identical, including the registers' 
layout, but their debug info is recorded in two different formats.  Is 
this something multi-arch is supposed to handle?

Note that the SGI 64-bit dwarf2 format is not one of the formats for 
which there's a reader available in the GDB distribution.  So basically 
we are talking about an unsupported debug info format, which in principle 
would require a separate *read.c module, along with coffread.c, 
dwarf2read.c, etc.

Am I missing something?

Of course, since the difference in the two dwarf2 formats is not too 
large, I could somehow sneak this in without writing a full-fledged debug 
info reader.  But would this be accepted, and if so, how, if at all, can I 
use the multi-arch infrastructure to control this?

Assuming that multi-arch somehow can be tweaked into doing this, my next 
question is: how do I set things up for GDB to identify the debug info 
format automatically?  That is, if I type "gdb myprog", how can GDB find 
out that `myprog' is a 64-bit executable and automatically switch to the 
64bit ABI architecture?

More generally, what facilities are there in gdbarch to identify the 
architecture of the debuggee automatically?  (My impression is that there 
are no such facilities and that the user should do that manually from 
inside GDB, but perhaps I'm missing something.)

Thanks in advance for any help.

Re: GDB on SGI Irix 6.5

[Daniel Berlin]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> > Date: Thu, 17 May 2001 12:40:41 -0400 (EDT)
> > From: Daniel Berlin <dan@www.cgsoftware.com>
> > >
> > > > We should support 64 bit dwarf2 already, for the most part.
> > >
> > > Since when?
> > Well, since about august of last year or something.
> 
> My sources are much newer, so I should already have what you
> describe.
> 
> > If you look at dwarf2read.c, you'll notice it handles offset sizes of both
> > 4 and 8.
> > read_initial_length takes care of figuring out which offset size we have.
> 
> Thanks, I will look deeper into this.  I understand that David says a
> failure with 64-bit Irix 6 executables is expected, though.  However,
> I wonder: you seem to say that your new reader does succeed to work on
> Irix?  Or was the 64-bit support you meant tested on platforms other
> than Irix?
Other than IRIX.
I forgot that IRIX uses a non 2.1 compliant 64 bit dwarf2.
I've verified it works with 2.1 compliant 64 bit dwarf2.


-- 
""-Steven Wright

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

> Date: Thu, 17 May 2001 10:13:35 -0700 (PDT)
> From: David B Anderson <davea@quasar.engr.sgi.com>
> 
> Ben Gamsa's patch on my website is a crude version of the above
> (not suitable for inclusion in gdb, but at least it has the
> key changes IRIX6 elf64 dwarf2 requires, for an older gdb).
> (patch is not multi-arch.)
> See the end of the page
> 	http://reality.sgi.com/davea/objectinfo.html
> (which Eli already noticed).

Yes, I've got that patch.  I will look into it and see how can I
modify it to make it acceptable for inclusion in GDB.

> I'm on vacation all week, but I'll apply Eli's patches
> and try out gdb asap.

Thanks!

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

> Date: Thu, 17 May 2001 12:40:41 -0400 (EDT)
> From: Daniel Berlin <dan@www.cgsoftware.com>
> >
> > > We should support 64 bit dwarf2 already, for the most part.
> >
> > Since when?
> Well, since about august of last year or something.

My sources are much newer, so I should already have what you
describe.

> If you look at dwarf2read.c, you'll notice it handles offset sizes of both
> 4 and 8.
> read_initial_length takes care of figuring out which offset size we have.

Thanks, I will look deeper into this.  I understand that David says a
failure with 64-bit Irix 6 executables is expected, though.  However,
I wonder: you seem to say that your new reader does succeed to work on
Irix?  Or was the 64-bit support you meant tested on platforms other
than Irix?

Re: GDB on SGI Irix 6.5

[David B Anderson]

Daniel Berlin wrote:
|On Thu, 17 May 2001, Eli Zaretskii wrote:
|
|>
|> On Thu, 17 May 2001, Daniel Berlin wrote:
|>
|> > We should support 64 bit dwarf2 already, for the most part.
|>
|> Since when?
|Well, since about august of last year or something.
|
|The main difference between 64 bit dwarf2, and 32 bit dwarf2, is, of
|course, the offset sizes.
|
|The DWARF2.1 standard says that the cu header's initial length will tell
|us whether we are dealing with 4 byte offsets or 8 byte offsets.
|
|If you look at dwarf2read.c, you'll notice it handles offset sizes of both
|4 and 8.
|read_initial_length takes care of figuring out which offset size we have.
|
|
|> It's possible that I have an outdated tree, in which case I'm sorry for
|> the line noise.


The 64bit dwarf2 that is read by read_initial_length is based on
dwarf 2.1, designed in 2000.  SGI 64bit dwarf2 was designed in
the early 1990's.  SGI made offsets etc 64bit in elf64
(and offsets etc 32bits in elf32).    
(basically we could not bring ourselves to limit dwarf 
offsets to 32 bits in an elf64 file...)

Anyway,  to be correct for IRIX6,  read_initial_length
needs to know it is IRIX elf64 and then
	 /* UNTESTED, NOT ALL THAT NEEDS TO BE DONE probably */
         cu_header->initial_length_size = 8;
         cu_header->offset_size = 8;
at least gives the right sizes.

Ben Gamsa's patch on my website is a crude version of the above
(not suitable for inclusion in gdb, but at least it has the
key changes IRIX6 elf64 dwarf2 requires, for an older gdb).
(patch is not multi-arch.)
See the end of the page
	http://reality.sgi.com/davea/objectinfo.html
(which Eli already noticed).

I'm on vacation all week, but I'll apply Eli's patches
and try out gdb asap.  Hopefully tonight or tomorrow night.
Been kind of behind in email due to vacation.

Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/

Re: GDB on SGI Irix 6.5

[Daniel Berlin]

On Thu, 17 May 2001, Eli Zaretskii wrote:

>
> On Thu, 17 May 2001, Daniel Berlin wrote:
>
> > We should support 64 bit dwarf2 already, for the most part.
>
> Since when?
Well, since about august of last year or something.

The main difference between 64 bit dwarf2, and 32 bit dwarf2, is, of
course, the offset sizes.

The DWARF2.1 standard says that the cu header's initial length will tell
us whether we are dealing with 4 byte offsets or 8 byte offsets.

If you look at dwarf2read.c, you'll notice it handles offset sizes of both
4 and 8.
read_initial_length takes care of figuring out which offset size we have.


> It's possible that I have an outdated tree, in which case I'm sorry for
> the line noise.
>

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

On Thu, 17 May 2001, Daniel Berlin wrote:

> We should support 64 bit dwarf2 already, for the most part.

Since when?

It's possible that I have an outdated tree, in which case I'm sorry for 
the line noise.

Re: GDB on SGI Irix 6.5

[Daniel Berlin]

On Thu, 17 May 2001, Eli Zaretskii wrote:

>
> On Thu, 17 May 2001, I wrote:
>
> > Debugging GDB with itself, I see that cu_header.version is zero,
> > probably because of the different format of the dwarf2 info used by
> > the 64-bit executables.
> >
> > Where can I find the information about this format, and how it differs
> > from the standard dwarf2?
>
> Looks like I found the info (on your site, David ;-).  So I'll ask more
> questions if what I read is unclear.  I also found a patch there that
> might help me.

We should support 64 bit dwarf2 already, for the most part.
I know the new reader does it, and I believe that reading the cu header
was one of the few routines I didn't change (Unless i'm completely
misremembering).
--Dan

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

On Thu, 17 May 2001, I wrote:

> Debugging GDB with itself, I see that cu_header.version is zero,
> probably because of the different format of the dwarf2 info used by
> the 64-bit executables.
> 
> Where can I find the information about this format, and how it differs
> from the standard dwarf2?

Looks like I found the info (on your site, David ;-).  So I'll ask more 
questions if what I read is unclear.  I also found a patch there that 
might help me.

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

> Date: Sat, 21 Apr 2001 13:07:12 -0700 (PDT)
> From: David B Anderson <davea@quasar.engr.sgi.com>
> 
> n32 and 64 use dwarf2 debug information.
> For -64 IRIX cc/CC/etc dwarf2 has 64bit offsets and lengths
> (which goes beyond the literal dwarf2 standard -- 
> when using elf64 we decided to use 64bit offsets in dwarf in case
> a section got beyond what 32bits could address).
> 
> Because of the dwarf2-by-IRIX difference from standard dwarf2
> a multi-arch for IRIX -64 using IRIX dwarf2-64 seems necessary,
> but that is a separate topic

Okay, I'm now staring at this topic, and it stares right back at me ;-)

Trying to debug a 64-bit executable produces the following error
message:

  Dwarf Error: wrong version in compilation unit header.

This comes from the following fragment in
dwarf2read.c:dwarf2_build_psymtabs_hard:

  while ((unsigned int) (info_ptr - dwarf_info_buffer)
         + ((info_ptr - dwarf_info_buffer) % 4) < dwarf_info_size)
    {
      struct comp_unit_head cu_header;
      beg_of_comp_unit = info_ptr;
      info_ptr = read_comp_unit_head (&cu_header, info_ptr, abfd);

      if (cu_header.version != 2)
        {
          error ("Dwarf Error: wrong version in compilation unit header.");
          return;
        }

Debugging GDB with itself, I see that cu_header.version is zero,
probably because of the different format of the dwarf2 info used by
the 64-bit executables.

Where can I find the information about this format, and how it differs
from the standard dwarf2?  "man dwarf" mumbles something about
/usr/share/src/compiler/dwarf/dwarf.v2.mm, but it doesn't exist on
this box, probably because they didn't install some optional package.
Is there any other place to find this document?

TIA

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

> Date: Sat, 21 Apr 2001 13:07:12 -0700 (PDT)
> From: David B Anderson <davea@quasar.engr.sgi.com>
[lots of useful info omitted]
> Hope this makes sense (rather than adding confusion).

Yes, it makes a lot of sense.  Thanks!

Re: GDB on SGI Irix 6.5

[David B Anderson]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
|> >  - What should I do about the different ABIs?  At least 3 come to
|> >    mind: O32, N32, and N64.  They have subtly different layouts of
|> >    registers, so if I need to set things up for more than a single
|> >    ABI, I'll need to know what's the current say-so about how this
|> >    should be done (e.g., does gdbarch has some functionality for
|> >    dynamically computing the registers array?).
|> 
|> The register layouts for n32 and 64 are the same.
|> Pointer and int are different sizes, but the registers
|> themselves are the same and designated the same.
|> 
|> The register set for o32 is different, and should be the same as for
|> irix5.
|
|Is it correct to say that, in general, n32 and 64 ABIs are
|inappropriate for Irix 5?  In other words, does it make sense to
|support n32 and 64 ABIs only for Irix 6.x?

Exactly correct 
	IRIX5 had two ABIs
	o32 elf (not called o32 back then, but it is called that now) 
	coff    (xcoff whatever the right name is)

|> Recall that o32 uses the mdebug/third-eye format for debug info
|> while n32/64 uses dwarf2 exlusively for debug info
|
|Is it really dwarf2 or elf?  I don't have access to the SGI box where
|I'm writing this, but I seem to remember that elf was used by GDB to
|read the debug info.


Sorry, I was using sloppy wording.

We can lump all of the IRIX6 variants under one umbrella as
they are not different in any important sense from IRIX6.5
(or IRIX 6.5.x) for gdb's purposes.

o32, n32, and -64 for IRIX6.5 are all elf object format.
o32 n32 are Elf32. 
-64 is Elf64.

For debug information, o32 uses third-eye/mdebug
(.mdebug is the Elf section name MIPS/SGI assigned. Third-eye is
the company that invented the debug information format MIPS
adopted in the mid-80's for COFF and that MIPS/SGI 
kept (for o32) in the transition to Elf).

n32 and 64 use dwarf2 debug information.
For -64 IRIX cc/CC/etc dwarf2 has 64bit offsets and lengths
(which goes beyond the literal dwarf2 standard -- 
when using elf64 we decided to use 64bit offsets in dwarf in case
a section got beyond what 32bits could address).

Because of the dwarf2-by-IRIX difference from standard dwarf2
a multi-arch for IRIX -64 using IRIX dwarf2-64 seems necessary,
but that is a separate topic from the registers.

Repeating what I said earlier, from a *register* point of view,
n32 and -64 are the same. The same register names and
conventions and the same argument passing.
The distinction is that n32 is ILP32 and -64 is LP64:
there is no  difference in the hardware registers (names
or lengths or anything) between them. 
(ILP32: int, long, and pointer all 32 bits)
(LP64:  int 32 bits; long and pointer 64 bits)
(Both support long long and it is always 64 bits)

|> I am not much help in determining the 'right way to do things' for
|> gdb, but if there is any way I can help with building or
|> testing or anything on IRIX6.5, let me know.
|
|Thanks, I will probably ask you to build the current CVS version with
|the candidate patches, to make sure I didn't miss something.

Ok. Glad to help.
Just send me the patches when you are ready.
I'm going to be in meetings most of next week so
I may be a bit tardy in responding then.

Hope this makes sense (rather than adding confusion).
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/

Re: GDB on SGI Irix 6.5

[Paul Hilfinger]

 > Is it really dwarf2 or elf?  I don't have access to the SGI box where
 > I'm writing this, but I seem to remember that elf was used by GDB to
 > read the debug info.

No contradiction there: the file format is elf, containing dwarf
debugging information.

Paul Hilfinger

Re: GDB on SGI Irix 6.5

[Eli Zaretskii]

> Date: Thu, 19 Apr 2001 18:05:05 -0700 (PDT)
> From: David B Anderson <davea@quasar.engr.sgi.com>
> 
> >  - Should I make the change in tm-irix5.h, or should I leave it alone
> >    and create irix6x.h?  The issue here is that perhaps Irix 5 did
> >    work like tm-irix5.h says, and I won't want to break that.
> 
> I suggest creating tm-irix6.h

Yes, that's what I tend to do as well, thanks for the feedback.

> >  - What should I do about the different ABIs?  At least 3 come to
> >    mind: O32, N32, and N64.  They have subtly different layouts of
> >    registers, so if I need to set things up for more than a single
> >    ABI, I'll need to know what's the current say-so about how this
> >    should be done (e.g., does gdbarch has some functionality for
> >    dynamically computing the registers array?).
> 
> The register layouts for n32 and 64 are the same.
> Pointer and int are different sizes, but the registers
> themselves are the same and designated the same.
> 
> The register set for o32 is different, and should be the same as for
> irix5.

Is it correct to say that, in general, n32 and 64 ABIs are
inappropriate for Irix 5?  In other words, does it make sense to
support n32 and 64 ABIs only for Irix 6.x?

> Recall that o32 uses the mdebug/third-eye format for debug info
> while n32/64 uses dwarf2 exlusively for debug info

Is it really dwarf2 or elf?  I don't have access to the SGI box where
I'm writing this, but I seem to remember that elf was used by GDB to
read the debug info.

> I am not much help in determining the 'right way to do things' for
> gdb, but if there is any way I can help with building or
> testing or anything on IRIX6.5, let me know.

Thanks, I will probably ask you to build the current CVS version with
the candidate patches, to make sure I didn't miss something.

Re: GDB on SGI Irix 6.5

[David B Anderson]

>  - Should I make the change in tm-irix5.h, or should I leave it alone
>    and create irix6x.h?  The issue here is that perhaps Irix 5 did
>    work like tm-irix5.h says, and I won't want to break that.

I suggest creating tm-irix6.h
IMO it's misleading to keep using the irix5 designation for irix6
and will lead to difficulty. But I'm far far from being an expert
on gdb, so take this with  a grain of salt.

>  - What should I do about the different ABIs?  At least 3 come to
>    mind: O32, N32, and N64.  They have subtly different layouts of
>    registers, so if I need to set things up for more than a single
>    ABI, I'll need to know what's the current say-so about how this
>    should be done (e.g., does gdbarch has some functionality for
>    dynamically computing the registers array?).

The register layouts for n32 and 64 are the same.
Pointer and int are different sizes, but the registers
themselves are the same and designated the same.

The register set for o32 is different, and should be the same as for
irix5.

Recall that o32 uses the mdebug/third-eye format for debug info
while n32/64 uses dwarf2 exlusively for debug info
(should be irrelevant as far as registers go though).

I am not much help in determining the 'right way to do things' for
gdb, but if there is any way I can help with building or
testing or anything on IRIX6.5, let me know.

Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/