From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-id: <9502142321.AA02979@presto> X-SW-Source: 1995/msg00017.html | From: Ian Lance Taylor | 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 --