public inbox for gas2@sourceware.org
 help / color / mirror / Atom feed
From: gary@Intrepid.COM (Gary Funck)
To: gas2@cygnus.com
Subject: Re: gas - MIPS/ELF/DWARF probs
Date: Tue, 14 Feb 1995 15:22:00 -0000	[thread overview]
Message-ID: <9502142321.AA02979@presto> (raw)

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




             reply	other threads:[~1995-02-14 15:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-02-14 15:22 Gary Funck [this message]
1995-02-14 15:30 ` Ian Lance Taylor
  -- strict thread matches above, loose matches on Subject: below --
1995-02-14 14:31 Gary Funck
1995-02-14 14:44 ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9502142321.AA02979@presto \
    --to=gary@intrepid.com \
    --cc=gas2@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).