gas - MIPS/ELF/DWARF probs
Gary Funck
gary@Intrepid.COM
Tue Feb 14 15:22:00 GMT 1995
| 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
--
More information about the Gas2
mailing list