Re: gas - MIPS/ELF/DWARF probs

Re: gas - MIPS/ELF/DWARF probs

[Gary Funck]

| From: Ian Lance Taylor <ian@cygnus.com>
| Date: Tue, 14 Feb 1995 17:44:00 -0500
| Cc: gas2@cygnus.com
| In-Reply-To: < 9502142230.AA02803@presto > (gary@Intrepid.COM)
| Subject: Re: gas - MIPS/ELF/DWARF probs
| 
|    Date: Tue, 14 Feb 95 14:30:59 -0800
|    From: gary@Intrepid.COM (Gary Funck)
| 
|    However, the file config/obj-elf.c
|    "overrides" tc-mips.c's handling of operations such as ".previous",
|    ".2byte":
| 
| This is the wrong way around.  Actually, the pseudo-ops defined in
| tc-mips.c are used, provided they are defined.  You should be able to
| fix this problem by defining the relevant pseudo-ops in tc-mips.c, if
| OBJ_ELF is defined, to do the tc-mips local processing and then call
| the obj-elf.c routine.

OK -- thanks.  Just to clarify: it is considered OK for a tc-targ.c
routine to call an obj-format.c routine when processing these
pseudo-ops?

Related question: if this is the proper way to handle things, has
this problem already come up in a different ELF/DWARF port?
Is there a port (ie, Solaris) that already handles such things
properly, that I might use as a reference?

| 
|    For now, we just removed the check in mips_align(), which forces
|    alignment on the prior label.  
| 
| As you know, this is not really an acceptable solution.  Existing MIPS
| assembler code relies on this working.

roger.

| 
|    To work around these problems, we made following patches to tc-mips.c:
| 
| These patches are not really usable as is, because they don't include
| any context.  I don't know how you generated them, but please always
| generate patches using diff -c.
| 

Looks like I inadvertently specified "-c -p0", where the 0 is interpreted
as the number of lines of context (none) in this case.  I'll stick
with -c -p next time.  The patches _with_ context are shown below.

By the way, it seems that suggested fix of handling .#byte and .previous
in tc-mips.c will fix the assertion failure in mips_align(), but
this still leaves the question open (at least for me) as to the
best way to fix the handling of:

        .section        .debug
.L_D193:
        .4byte  .L_D193_e-.L_D193
        .2byte  0x14
        .2byte  0x12
        .4byte  .L_D198
        .2byte  0x38
        .asciiz "_i_Object__free"
        .2byte  0x83
        .2byte  .L_t193_e-.L_t193
.L_t193:

Do the patches to md_apply_fix() below, look like the way to go?

*** targ-cpu.c.orig	Sun Feb 12 20:51:25 1995
--- targ-cpu.c	Sun Feb 12 21:29:50 1995
*************** md_apply_fix (fixP, valueP)
*** 5310,5316 ****
--- 5310,5324 ----
    unsigned char *buf;
    long insn, value;
  
+ #if 0
+   /*
+    * DWARF support may define something like:
+    *   .2byte L1-L2
+    * which is handled as a fix up.  The check below incorrectly bounces
+    * that construct.
+    */
    assert (fixP->fx_size == 4);
+ #endif
  
    value = *valueP;
    fixP->fx_addnumber = value;	/* Remember value for tc_gen_reloc */
*************** md_apply_fix (fixP, valueP)
*** 5334,5339 ****
--- 5342,5356 ----
        /* Nothing needed to do. The value comes from the reloc entry */
        break;
  
+ #if 1
+     case BFD_RELOC_16:
+       /* nothing to do - but better not be relocatable.
+        * Sixteen bit fixups are generated by the DWARF support.
+        */
+       assert(!fixP->fx_pcrel);
+       break;
+ #endif
+ 
      case BFD_RELOC_PCREL_HI16_S:
        /* The addend for this is tricky if it is internal, so we just
  	 do everything here rather than in bfd_perform_relocation.  */
*************** mips_align (to, fill, label)
*** 5583,5594 ****
--- 5600,5619 ----
    mips_emit_delays ();
    frag_align (to, fill);
    record_alignment (now_seg, to);
+ #if 0
+   /* obj-elf.c doesn't communicate with these routines, yet it
+    * overrides ".previous", ".2byte",  etc.  They should clear,
+    * but do not know how to clear, insn_label, which is passed
+    * in as "label" to this routine.  For now, we remove the
+    * ability to align the previous label.
+    */
    if (label != NULL)
      {
        assert (S_GET_SEGMENT (label) == now_seg);
        label->sy_frag = frag_now;
        S_SET_VALUE (label, (valueT) frag_now_fix ());
      }
+ #endif
  }
  
  /* Align to a given power of two.  .align 0 turns off the automatic


--
|  Gary Funck  		     gary@intrepid.com
|  Intrepid Technology Inc., Mountain View CA (415) 964-8135
--

Re: gas - MIPS/ELF/DWARF probs

[Ian Lance Taylor]

   Date: Tue, 14 Feb 95 15:21:55 -0800
   From: gary@Intrepid.COM (Gary Funck)

   OK -- thanks.  Just to clarify: it is considered OK for a tc-targ.c
   routine to call an obj-format.c routine when processing these
   pseudo-ops?

IMHO, yes.

   Related question: if this is the proper way to handle things, has
   this problem already come up in a different ELF/DWARF port?
   Is there a port (ie, Solaris) that already handles such things
   properly, that I might use as a reference?

Sure.  The MIPS port, itself, already overrides the ELF .section
directive.  It does MIPS specific stuff, and calls obj_elf_section.
Look at the end of md_pseudo_table in tc-mips.c (this may have been
added since the 2.5.2 release--if you don't know about the developer
snapshots for gas/binutils, ask me).

   Looks like I inadvertently specified "-c -p0", where the 0 is interpreted
   as the number of lines of context (none) in this case.  I'll stick
   with -c -p next time.  The patches _with_ context are shown below.

Thanks.

   By the way, it seems that suggested fix of handling .#byte and .previous
   in tc-mips.c will fix the assertion failure in mips_align(), but
   this still leaves the question open (at least for me) as to the
   best way to fix the handling of:

	   .section        .debug
   .L_D193:
	   .4byte  .L_D193_e-.L_D193
	   .2byte  0x14
	   .2byte  0x12
	   .4byte  .L_D198
	   .2byte  0x38
	   .asciiz "_i_Object__free"
	   .2byte  0x83
	   .2byte  .L_t193_e-.L_t193
   .L_t193:

   Do the patches to md_apply_fix() below, look like the way to go?

Yes, I believe that something along the lines of your patches is
correct.  Particularly if it works.

Ian

Re: gas - MIPS/ELF/DWARF probs

[Ian Lance Taylor]

   Date: Tue, 14 Feb 95 14:30:59 -0800
   From: gary@Intrepid.COM (Gary Funck)

   However, the file config/obj-elf.c
   "overrides" tc-mips.c's handling of operations such as ".previous",
   ".2byte":

This is the wrong way around.  Actually, the pseudo-ops defined in
tc-mips.c are used, provided they are defined.  You should be able to
fix this problem by defining the relevant pseudo-ops in tc-mips.c, if
OBJ_ELF is defined, to do the tc-mips local processing and then call
the obj-elf.c routine.

   For now, we just removed the check in mips_align(), which forces
   alignment on the prior label.  

As you know, this is not really an acceptable solution.  Existing MIPS
assembler code relies on this working.

   To work around these problems, we made following patches to tc-mips.c:

These patches are not really usable as is, because they don't include
any context.  I don't know how you generated them, but please always
generate patches using diff -c.

Ian

gas - MIPS/ELF/DWARF probs

[Gary Funck]

Hello,

Our company is working with the NYU GNAT team; we hope to develop
DWARF-based debugging support for Ada programs compiled by gnat
(GNU Ada Translator) and then debugged by gdb.  Paul Hilfinger
of Berkeley (hilfingr@tully.cs.berkeley.edu) is working on making
gdb Ada-aware.  We've been lurking on the gas2 list for a while now;
this is our first posting to this group.  We hope the following
message is "on topic", and look forward to your comments/help.

                          -----

We are targetting SGI's IRIX 5.x operating system, and have configured
gcc-2.6.2 to generate DWARF, and to use the GNU assembler
(binutils-2.5.2).  Although, IRIX 5.x tools still use the "MIPS
Debug" format (a derivative of the Third Eye dbx-like debugging
format), their debugger knows how to debug either MDEBUG or DWARF.
We eventually plan to target IRIX 6.x, which uses DWARF info.
directly.  Thus, IRIX 5.x seemed a reasonable starting point for
experimentation.

We've run into (what we think are) a few gas bugs/problems. Please
find them dsscribed below.  As you'll see, the problems came up
when we tried to build objc (Objective C) using the boostrapped xgcc.
We built Objective C by mistake, however, we believe that the
same gas problems will come up whether/not we're building objc.

The problems are described below:


When copiling objc/hash.c

We end up with the following code:

.L_D215:
	.4byte	0x4
	.previous
	.align	2
	.globl	hash_delete

The align directive gets an assertion failure in the procedure,
mips_align in config/tc-mips.c:


/* Align the current frag to a given power of two.  The MIPS assembler
   also automatically adjusts any preceding label.  */

static void
mips_align (to, fill, label)
     int to;
     int fill;
     symbolS *label;
{
  mips_emit_delays ();
  frag_align (to, fill);
  record_alignment (now_seg, to);
  /* obj-elf.c doesn't communicate with these routines, yet it
   * overrides ".previous", ".2byte",  etc.  They should clear,
   * but do not know how to clear, insn_label, which is passed
   * in as "label" to this routine.  For now, we remove the
   * ability to align the previous label.
   */
  if (label != NULL)
    {
      assert (S_GET_SEGMENT (label) == now_seg);
      label->sy_frag = frag_now;
      S_SET_VALUE (label, (valueT) frag_now_fix ());
    }
}

The check for (label != NULL) above passes, and the assertion that
follows fails.  The 'label' formal parameter is in fact the current
instruction's label:

/* Symbol labelling the current insn.  */
static symbolS *insn_label;

Normally, this insn_label variable is reset to NULL by assembler
statements which generate code/data.  By "normally", we mean that
tc-mips.c does the right thing.  However, the file config/obj-elf.c
"overrides" tc-mips.c's handling of operations such as ".previous",
".2byte":

  {"comm", obj_elf_common, 0},
  {"ident", obj_elf_ident, 0},
  {"local", obj_elf_local, 0},
  {"previous", obj_elf_previous, 0},
  {"section", obj_elf_section, 0},
  {"size", obj_elf_size, 0},
  {"type", obj_elf_type, 0},
  {"version", obj_elf_version, 0},
  {"weak", obj_elf_weak, 0},

/* These are used for stabs-in-elf configurations.  */
  {"line", obj_elf_line, 0},

  /* These are used for dwarf. */
  {"2byte", cons, 2},
  {"4byte", cons, 4},
  {"8byte", cons, 8},

  /* We need to trap the section changing calls to handle .previous.  */
  {"data", obj_elf_data, 0},
  {"text", obj_elf_text, 0},

One thing that obj-elf.c does _not_ do, however is to reset tc-mips.c's
idea of the current instruction label.  So when the .align opcode
comes along, it is not overridden, and it in turn checks for
the insn_label, which now has a different section, than the section
resulting from popping to the previous section via the ".previous" opcode.

For now, we just removed the check in mips_align(), which forces
alignment on the prior label.  It seems there is also the question
as to whether ".previous" must remember the previous label or not
as well as the question of how obj-elf.c should communicate with
tc-mips.c.

The second problem has to do with the fact that the DWARF code
generation may generate code along the following lines (line
3256 in objc/Object.s):

        .section        .debug
.L_D193:
        .4byte  .L_D193_e-.L_D193
        .2byte  0x14
        .2byte  0x12
        .4byte  .L_D198
        .2byte  0x38
        .asciiz "_i_Object__free"
        .2byte  0x83
        .2byte  .L_t193_e-.L_t193
.L_t193:


That last ".2byte" pseudo-op has a foward reference to L_t193_e, and
this is apparently handled as a "fixup" in gas.  The relocation value
is given as "BFD_RELOC_16" ... even though this value will in fact
be absolute and not relocatable (it is the difference of two reloacatable
items).

The procedure "md_apply_fix" in config/mips/tc-mips.c is supposed to
handle fixups, however, it does not have an entry in its case
statement for items with BFD_RELOC_16, so the default case alternative
is executed, and this triggers an internal error.

Earlier in the handling of this ".2byte" directive, we ran
into the following assertion, at the very beginning of
mips_apply_fix() which fails:

  assert (fixP->fx_size == 4);

To work around these problems, we made following patches to tc-mips.c:

*** targ-cpu.c.orig	Sun Feb 12 20:51:25 1995
--- targ-cpu.c	Sun Feb 12 21:29:50 1995
*************** md_apply_fix (fixP, valueP)
*** 5312 ****
--- 5313,5319 ----
+ #if 0
+   /*
+    * DWARF support may define something like:
+    *   .2byte L1-L2
+    * which is handled as a fix up.  The check below incorrectly bounces
+    * that construct.
+    */
*************** md_apply_fix (fixP, valueP)
*** 5313 ****
--- 5321 ----
+ #endif
*************** md_apply_fix (fixP, valueP)
*** 5336 ****
--- 5345,5353 ----
+ #if 1
+     case BFD_RELOC_16:
+       /* nothing to do - but better not be relocatable.
+        * Sixteen bit fixups are generated by the DWARF support.
+        */
+       assert(!fixP->fx_pcrel);
+       break;
+ #endif
+ 
*************** mips_align (to, fill, label)
*** 5585 ****
--- 5603,5609 ----
+ #if 0
+   /* obj-elf.c doesn't communicate with these routines, yet it
+    * overrides ".previous", ".2byte",  etc.  They should clear,
+    * but do not know how to clear, insn_label, which is passed
+    * in as "label" to this routine.  For now, we remove the
+    * ability to align the previous label.
+    */
*************** mips_align (to, fill, label)
*** 5591 ****
--- 5616 ----
+ #endif

We view the patches above are really just temporary workarounds.

Has anyone seen and/or fixed these problems?

--
|  Gary Funck  		     gary@intrepid.com
|  Intrepid Technology Inc., Mountain View CA (415) 964-8135
--