* powerpc64-linux infrastructure 5 of 6
@ 2001-08-08 6:19 Alan Modra
2001-08-08 13:47 ` Geoff Keating
0 siblings, 1 reply; 8+ messages in thread
From: Alan Modra @ 2001-08-08 6:19 UTC (permalink / raw)
To: binutils
Put relocs in the opcode table.
include/opcode/ChangeLog
1999-10-25 Torbjorn Granlund <tege@swox.com>
* ppc.h (struct powerpc_operand): New field `reloc'.
opcodes/ChangeLog
1999-10-25 Torbjorn Granlund <tege@swox.com>
* ppc-opc.c: Include "bfd.h".
(powerpc_operands): Add new field for reloc type.
Applying to mainline.
--
Alan Modra
Index: include/opcode/ppc.h
===================================================================
RCS file: /cvs/src/src/include/opcode/ppc.h,v
retrieving revision 1.4
diff -u -p -r1.4 ppc.h
--- ppc.h 2001/03/14 02:27:44 1.4
+++ ppc.h 2001/08/08 08:30:10
@@ -144,6 +144,7 @@ struct powerpc_operand
/* One bit syntax flags. */
unsigned long flags;
+ int reloc;
};
/* Elements in the table are retrieved by indexing with values from
Index: opcodes/ppc-opc.c
===================================================================
RCS file: /cvs/src/src/opcodes/ppc-opc.c,v
retrieving revision 1.13
diff -u -p -r1.13 ppc-opc.c
--- ppc-opc.c 2001/07/03 18:37:39 1.13
+++ ppc-opc.c 2001/08/08 08:30:13
@@ -24,6 +24,7 @@ Software Foundation, 59 Temple Place - S
#include "sysdep.h"
#include "opcode/ppc.h"
#include "opintl.h"
+#include "bfd.h"
/* This file holds the PowerPC opcode table. The opcode table
includes almost all of the extended instruction mnemonics. This
@@ -93,241 +94,247 @@ const struct powerpc_operand powerpc_ope
/* The zero index is used to indicate the end of the list of
operands. */
#define UNUSED 0
- { 0, 0, 0, 0, 0 },
+ { 0, 0, 0, 0, 0, 0},
/* The BA field in an XL form instruction. */
#define BA UNUSED + 1
#define BA_MASK (0x1f << 16)
- { 5, 16, 0, 0, PPC_OPERAND_CR },
+ { 5, 16, 0, 0, PPC_OPERAND_CR, 0 },
/* The BA field in an XL form instruction when it must be the same
as the BT field in the same instruction. */
#define BAT BA + 1
- { 5, 16, insert_bat, extract_bat, PPC_OPERAND_FAKE },
+ { 5, 16, insert_bat, extract_bat, PPC_OPERAND_FAKE, 0 },
/* The BB field in an XL form instruction. */
#define BB BAT + 1
#define BB_MASK (0x1f << 11)
- { 5, 11, 0, 0, PPC_OPERAND_CR },
+ { 5, 11, 0, 0, PPC_OPERAND_CR, 0 },
/* The BB field in an XL form instruction when it must be the same
as the BA field in the same instruction. */
#define BBA BB + 1
- { 5, 11, insert_bba, extract_bba, PPC_OPERAND_FAKE },
+ { 5, 11, insert_bba, extract_bba, PPC_OPERAND_FAKE, 0 },
/* The BD field in a B form instruction. The lower two bits are
forced to zero. */
#define BD BBA + 1
- { 16, 0, insert_bd, extract_bd, PPC_OPERAND_RELATIVE | PPC_OPERAND_SIGNED },
+ { 16, 0, insert_bd, extract_bd, PPC_OPERAND_RELATIVE | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_B16 },
/* The BD field in a B form instruction when absolute addressing is
used. */
#define BDA BD + 1
- { 16, 0, insert_bd, extract_bd, PPC_OPERAND_ABSOLUTE | PPC_OPERAND_SIGNED },
+ { 16, 0, insert_bd, extract_bd, PPC_OPERAND_ABSOLUTE | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_BA16 },
/* The BD field in a B form instruction when the - modifier is used.
This sets the y bit of the BO field appropriately. */
#define BDM BDA + 1
- { 16, 0, insert_bdm, extract_bdm,
- PPC_OPERAND_RELATIVE | PPC_OPERAND_SIGNED },
+ { 16, 0, insert_bdm, extract_bdm, PPC_OPERAND_RELATIVE | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_B16 },
/* The BD field in a B form instruction when the - modifier is used
and absolute address is used. */
#define BDMA BDM + 1
- { 16, 0, insert_bdm, extract_bdm,
- PPC_OPERAND_ABSOLUTE | PPC_OPERAND_SIGNED },
+ { 16, 0, insert_bdm, extract_bdm, PPC_OPERAND_ABSOLUTE | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_BA16 },
/* The BD field in a B form instruction when the + modifier is used.
This sets the y bit of the BO field appropriately. */
#define BDP BDMA + 1
- { 16, 0, insert_bdp, extract_bdp,
- PPC_OPERAND_RELATIVE | PPC_OPERAND_SIGNED },
+ { 16, 0, insert_bdp, extract_bdp, PPC_OPERAND_RELATIVE | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_B16 },
/* The BD field in a B form instruction when the + modifier is used
and absolute addressing is used. */
#define BDPA BDP + 1
- { 16, 0, insert_bdp, extract_bdp,
- PPC_OPERAND_ABSOLUTE | PPC_OPERAND_SIGNED },
+ { 16, 0, insert_bdp, extract_bdp, PPC_OPERAND_ABSOLUTE | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_BA16 },
/* The BF field in an X or XL form instruction. */
#define BF BDPA + 1
- { 3, 23, 0, 0, PPC_OPERAND_CR },
+ { 3, 23, 0, 0, PPC_OPERAND_CR, 0 },
/* An optional BF field. This is used for comparison instructions,
in which an omitted BF field is taken as zero. */
#define OBF BF + 1
- { 3, 23, 0, 0, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL },
+ { 3, 23, 0, 0, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL, 0 },
/* The BFA field in an X or XL form instruction. */
#define BFA OBF + 1
- { 3, 18, 0, 0, PPC_OPERAND_CR },
+ { 3, 18, 0, 0, PPC_OPERAND_CR, 0 },
/* The BI field in a B form or XL form instruction. */
#define BI BFA + 1
#define BI_MASK (0x1f << 16)
- { 5, 16, 0, 0, PPC_OPERAND_CR },
+ { 5, 16, 0, 0, PPC_OPERAND_CR, 0 },
/* The BO field in a B form instruction. Certain values are
illegal. */
#define BO BI + 1
#define BO_MASK (0x1f << 21)
- { 5, 21, insert_bo, extract_bo, 0 },
+ { 5, 21, insert_bo, extract_bo, 0, 0 },
/* The BO field in a B form instruction when the + or - modifier is
used. This is like the BO field, but it must be even. */
#define BOE BO + 1
- { 5, 21, insert_boe, extract_boe, 0 },
+ { 5, 21, insert_boe, extract_boe, 0, 0 },
/* The BT field in an X or XL form instruction. */
#define BT BOE + 1
- { 5, 21, 0, 0, PPC_OPERAND_CR },
+ { 5, 21, 0, 0, PPC_OPERAND_CR, 0 },
/* The condition register number portion of the BI field in a B form
or XL form instruction. This is used for the extended
conditional branch mnemonics, which set the lower two bits of the
BI field. This field is optional. */
#define CR BT + 1
- { 3, 18, 0, 0, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL },
+ { 3, 18, 0, 0, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL, 0 },
/* The D field in a D form instruction. This is a displacement off
a register, and implies that the next operand is a register in
parentheses. */
#define D CR + 1
- { 16, 0, 0, 0, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED },
+ { 16, 0, 0, 0, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_TOC16 },
/* The DS field in a DS form instruction. This is like D, but the
lower two bits are forced to zero. */
#define DS D + 1
- { 16, 0, insert_ds, extract_ds, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED },
+ { 16, 0, insert_ds, extract_ds, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_TOC16 },
/* The E field in a wrteei instruction. */
#define E DS + 1
- { 1, 15, 0, 0, 0 },
+ { 1, 15, 0, 0, 0, 0 },
/* The FL1 field in a POWER SC form instruction. */
#define FL1 E + 1
- { 4, 12, 0, 0, 0 },
+ { 4, 12, 0, 0, 0, 0 },
/* The FL2 field in a POWER SC form instruction. */
#define FL2 FL1 + 1
- { 3, 2, 0, 0, 0 },
+ { 3, 2, 0, 0, 0, 0 },
/* The FLM field in an XFL form instruction. */
#define FLM FL2 + 1
- { 8, 17, 0, 0, 0 },
+ { 8, 17, 0, 0, 0, 0 },
/* The FRA field in an X or A form instruction. */
#define FRA FLM + 1
#define FRA_MASK (0x1f << 16)
- { 5, 16, 0, 0, PPC_OPERAND_FPR },
+ { 5, 16, 0, 0, PPC_OPERAND_FPR, 0 },
/* The FRB field in an X or A form instruction. */
#define FRB FRA + 1
#define FRB_MASK (0x1f << 11)
- { 5, 11, 0, 0, PPC_OPERAND_FPR },
+ { 5, 11, 0, 0, PPC_OPERAND_FPR, 0 },
/* The FRC field in an A form instruction. */
#define FRC FRB + 1
#define FRC_MASK (0x1f << 6)
- { 5, 6, 0, 0, PPC_OPERAND_FPR },
+ { 5, 6, 0, 0, PPC_OPERAND_FPR, 0 },
/* The FRS field in an X form instruction or the FRT field in a D, X
or A form instruction. */
#define FRS FRC + 1
#define FRT FRS
- { 5, 21, 0, 0, PPC_OPERAND_FPR },
+ { 5, 21, 0, 0, PPC_OPERAND_FPR, 0 },
/* The FXM field in an XFX instruction. */
#define FXM FRS + 1
#define FXM_MASK (0xff << 12)
- { 8, 12, 0, 0, 0 },
+ { 8, 12, 0, 0, 0, 0 },
/* The L field in a D or X form instruction. */
#define L FXM + 1
- { 1, 21, 0, 0, PPC_OPERAND_OPTIONAL },
+ { 1, 21, 0, 0, PPC_OPERAND_OPTIONAL, 0 },
/* The LEV field in a POWER SC form instruction. */
#define LEV L + 1
- { 7, 5, 0, 0, 0 },
+ { 7, 5, 0, 0, 0, 0 },
/* The LI field in an I form instruction. The lower two bits are
forced to zero. */
#define LI LEV + 1
- { 26, 0, insert_li, extract_li, PPC_OPERAND_RELATIVE | PPC_OPERAND_SIGNED },
+ { 26, 0, insert_li, extract_li, PPC_OPERAND_RELATIVE | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_B26 },
/* The LI field in an I form instruction when used as an absolute
address. */
#define LIA LI + 1
- { 26, 0, insert_li, extract_li, PPC_OPERAND_ABSOLUTE | PPC_OPERAND_SIGNED },
+ { 26, 0, insert_li, extract_li, PPC_OPERAND_ABSOLUTE | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_BA26 },
/* The MB field in an M form instruction. */
#define MB LIA + 1
#define MB_MASK (0x1f << 6)
- { 5, 6, 0, 0, 0 },
+ { 5, 6, 0, 0, 0, 0 },
/* The ME field in an M form instruction. */
#define ME MB + 1
#define ME_MASK (0x1f << 1)
- { 5, 1, 0, 0, 0 },
+ { 5, 1, 0, 0, 0, 0 },
/* The MB and ME fields in an M form instruction expressed a single
operand which is a bitmask indicating which bits to select. This
is a two operand form using PPC_OPERAND_NEXT. See the
description in opcode/ppc.h for what this means. */
#define MBE ME + 1
- { 5, 6, 0, 0, PPC_OPERAND_OPTIONAL | PPC_OPERAND_NEXT },
- { 32, 0, insert_mbe, extract_mbe, 0 },
+ { 5, 6, 0, 0, PPC_OPERAND_OPTIONAL | PPC_OPERAND_NEXT, 0 },
+ { 32, 0, insert_mbe, extract_mbe, 0, 0 },
/* The MB or ME field in an MD or MDS form instruction. The high
bit is wrapped to the low end. */
#define MB6 MBE + 2
#define ME6 MB6
#define MB6_MASK (0x3f << 5)
- { 6, 5, insert_mb6, extract_mb6, 0 },
+ { 6, 5, insert_mb6, extract_mb6, 0, 0 },
/* The NB field in an X form instruction. The value 32 is stored as
0. */
#define NB MB6 + 1
- { 6, 11, insert_nb, extract_nb, 0 },
+ { 6, 11, insert_nb, extract_nb, 0, 0 },
/* The NSI field in a D form instruction. This is the same as the
SI field, only negated. */
#define NSI NB + 1
{ 16, 0, insert_nsi, extract_nsi,
- PPC_OPERAND_NEGATIVE | PPC_OPERAND_SIGNED },
+ PPC_OPERAND_NEGATIVE | PPC_OPERAND_SIGNED, 0 },
/* The RA field in an D, DS, X, XO, M, or MDS form instruction. */
#define RA NSI + 1
#define RA_MASK (0x1f << 16)
- { 5, 16, 0, 0, PPC_OPERAND_GPR },
+ { 5, 16, 0, 0, PPC_OPERAND_GPR, 0 },
/* The RA field in a D or X form instruction which is an updating
load, which means that the RA field may not be zero and may not
equal the RT field. */
#define RAL RA + 1
- { 5, 16, insert_ral, 0, PPC_OPERAND_GPR },
+ { 5, 16, insert_ral, 0, PPC_OPERAND_GPR, 0 },
/* The RA field in an lmw instruction, which has special value
restrictions. */
#define RAM RAL + 1
- { 5, 16, insert_ram, 0, PPC_OPERAND_GPR },
+ { 5, 16, insert_ram, 0, PPC_OPERAND_GPR, 0 },
/* The RA field in a D or X form instruction which is an updating
store or an updating floating point load, which means that the RA
field may not be zero. */
#define RAS RAM + 1
- { 5, 16, insert_ras, 0, PPC_OPERAND_GPR },
+ { 5, 16, insert_ras, 0, PPC_OPERAND_GPR, 0 },
/* The RB field in an X, XO, M, or MDS form instruction. */
#define RB RAS + 1
#define RB_MASK (0x1f << 11)
- { 5, 11, 0, 0, PPC_OPERAND_GPR },
+ { 5, 11, 0, 0, PPC_OPERAND_GPR, 0 },
/* The RB field in an X form instruction when it must be the same as
the RS field in the instruction. This is used for extended
mnemonics like mr. */
#define RBS RB + 1
- { 5, 1, insert_rbs, extract_rbs, PPC_OPERAND_FAKE },
+ { 5, 1, insert_rbs, extract_rbs, PPC_OPERAND_FAKE, 0 },
/* The RS field in a D, DS, X, XFX, XS, M, MD or MDS form
instruction or the RT field in a D, DS, X, XFX or XO form
@@ -335,101 +343,101 @@ const struct powerpc_operand powerpc_ope
#define RS RBS + 1
#define RT RS
#define RT_MASK (0x1f << 21)
- { 5, 21, 0, 0, PPC_OPERAND_GPR },
+ { 5, 21, 0, 0, PPC_OPERAND_GPR, 0 },
/* The SH field in an X or M form instruction. */
#define SH RS + 1
#define SH_MASK (0x1f << 11)
- { 5, 11, 0, 0, 0 },
+ { 5, 11, 0, 0, 0, 0 },
/* The SH field in an MD form instruction. This is split. */
#define SH6 SH + 1
#define SH6_MASK ((0x1f << 11) | (1 << 1))
- { 6, 1, insert_sh6, extract_sh6, 0 },
+ { 6, 1, insert_sh6, extract_sh6, 0, 0 },
/* The SI field in a D form instruction. */
#define SI SH6 + 1
- { 16, 0, 0, 0, PPC_OPERAND_SIGNED },
+ { 16, 0, 0, 0, PPC_OPERAND_SIGNED, 0 },
/* The SI field in a D form instruction when we accept a wide range
of positive values. */
#define SISIGNOPT SI + 1
- { 16, 0, 0, 0, PPC_OPERAND_SIGNED | PPC_OPERAND_SIGNOPT },
+ { 16, 0, 0, 0, PPC_OPERAND_SIGNED | PPC_OPERAND_SIGNOPT, 0 },
/* The SPR field in an XFX form instruction. This is flipped--the
lower 5 bits are stored in the upper 5 and vice- versa. */
#define SPR SISIGNOPT + 1
#define SPR_MASK (0x3ff << 11)
- { 10, 11, insert_spr, extract_spr, 0 },
+ { 10, 11, insert_spr, extract_spr, 0, 0 },
/* The BAT index number in an XFX form m[ft]ibat[lu] instruction. */
#define SPRBAT SPR + 1
#define SPRBAT_MASK (0x3 << 17)
- { 2, 17, 0, 0, 0 },
+ { 2, 17, 0, 0, 0, 0 },
/* The SPRG register number in an XFX form m[ft]sprg instruction. */
#define SPRG SPRBAT + 1
#define SPRG_MASK (0x3 << 16)
- { 2, 16, 0, 0, 0 },
+ { 2, 16, 0, 0, 0, 0 },
/* The SR field in an X form instruction. */
#define SR SPRG + 1
- { 4, 16, 0, 0, 0 },
+ { 4, 16, 0, 0, 0, 0 },
/* The SV field in a POWER SC form instruction. */
#define SV SR + 1
- { 14, 2, 0, 0, 0 },
+ { 14, 2, 0, 0, 0, 0 },
/* The TBR field in an XFX form instruction. This is like the SPR
field, but it is optional. */
#define TBR SV + 1
- { 10, 11, insert_tbr, extract_tbr, PPC_OPERAND_OPTIONAL },
+ { 10, 11, insert_tbr, extract_tbr, PPC_OPERAND_OPTIONAL, 0 },
/* The TO field in a D or X form instruction. */
#define TO TBR + 1
#define TO_MASK (0x1f << 21)
- { 5, 21, 0, 0, 0 },
+ { 5, 21, 0, 0, 0, 0 },
/* The U field in an X form instruction. */
#define U TO + 1
- { 4, 12, 0, 0, 0 },
+ { 4, 12, 0, 0, 0, 0 },
/* The UI field in a D form instruction. */
#define UI U + 1
- { 16, 0, 0, 0, 0 },
+ { 16, 0, 0, 0, 0, 0 },
/* The VA field in a VA, VX or VXR form instruction. */
#define VA UI + 1
#define VA_MASK (0x1f << 16)
- {5, 16, 0, 0, PPC_OPERAND_VR},
+ {5, 16, 0, 0, PPC_OPERAND_VR, 0},
/* The VB field in a VA, VX or VXR form instruction. */
#define VB VA + 1
#define VB_MASK (0x1f << 11)
- {5, 11, 0, 0, PPC_OPERAND_VR},
+ {5, 11, 0, 0, PPC_OPERAND_VR, 0},
/* The VC field in a VA form instruction. */
#define VC VB + 1
#define VC_MASK (0x1f << 6)
- {5, 6, 0, 0, PPC_OPERAND_VR},
+ {5, 6, 0, 0, PPC_OPERAND_VR, 0},
/* The VD or VS field in a VA, VX, VXR or X form instruction. */
#define VD VC + 1
#define VS VD
#define VD_MASK (0x1f << 21)
- {5, 21, 0, 0, PPC_OPERAND_VR},
+ {5, 21, 0, 0, PPC_OPERAND_VR, 0},
/* The SIMM field in a VX form instruction. */
#define SIMM VD + 1
- { 5, 16, 0, 0, PPC_OPERAND_SIGNED},
+ { 5, 16, 0, 0, PPC_OPERAND_SIGNED, 0},
/* The UIMM field in a VX form instruction. */
#define UIMM SIMM + 1
- { 5, 16, 0, 0, 0 },
+ { 5, 16, 0, 0, 0, 0 },
/* The SHB field in a VA form instruction. */
#define SHB UIMM + 1
- { 4, 6, 0, 0, 0 },
+ { 4, 6, 0, 0, 0, 0 },
};
/* The functions used to insert and extract complicated operands. */
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc64-linux infrastructure 5 of 6
2001-08-08 6:19 powerpc64-linux infrastructure 5 of 6 Alan Modra
@ 2001-08-08 13:47 ` Geoff Keating
2001-08-08 13:55 ` Torbjorn Granlund
0 siblings, 1 reply; 8+ messages in thread
From: Geoff Keating @ 2001-08-08 13:47 UTC (permalink / raw)
To: amodra; +Cc: binutils
> Put relocs in the opcode table.
This seems like a bad design. The opcode table is shared between
multiple ABIs and object file formats, and there's no reason to think
that the reloc for an instruction in aix-xcoff would be the same as
the one in powerpc SVR4. For instance,
/* The D field in a D form instruction. This is a displacement off
a register, and implies that the next operand is a register in
parentheses. */
#define D CR + 1
- { 16, 0, 0, 0, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED },
+ { 16, 0, 0, 0, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_TOC16 },
seems specific to the AIX and powerpc64 ABIs.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc64-linux infrastructure 5 of 6
2001-08-08 13:47 ` Geoff Keating
@ 2001-08-08 13:55 ` Torbjorn Granlund
2001-08-08 16:44 ` Alan Modra
0 siblings, 1 reply; 8+ messages in thread
From: Torbjorn Granlund @ 2001-08-08 13:55 UTC (permalink / raw)
To: Geoff Keating; +Cc: amodra, binutils
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
Geoff Keating <geoffk@geoffk.org> writes:
> Put relocs in the opcode table.
This seems like a bad design. The opcode table is shared between
multiple ABIs and object file formats, and there's no reason to think
that the reloc for an instruction in aix-xcoff would be the same as
the one in powerpc SVR4. For instance,
/* The D field in a D form instruction. This is a displacement off
a register, and implies that the next operand is a register in
parentheses. */
#define D CR + 1
- { 16, 0, 0, 0, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED },
+ { 16, 0, 0, 0, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED,
+ BFD_RELOC_PPC_TOC16 },
seems specific to the AIX and powerpc64 ABIs.
Yes, that field is only used for AIX / XCOFF.
It replaces an ugly chunk of ad-hoc code in tc-ppc.c.
Why do you think it is bad design?
--
Torbjörn
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc64-linux infrastructure 5 of 6
2001-08-08 13:55 ` Torbjorn Granlund
@ 2001-08-08 16:44 ` Alan Modra
2001-08-09 12:55 ` Geoff Keating
0 siblings, 1 reply; 8+ messages in thread
From: Alan Modra @ 2001-08-08 16:44 UTC (permalink / raw)
To: Torbjorn Granlund; +Cc: Geoff Keating, binutils
On Wed, Aug 08, 2001 at 10:55:37PM +0200, Torbjorn Granlund wrote:
> Geoff Keating <geoffk@geoffk.org> writes:
>
> > Put relocs in the opcode table.
>
> This seems like a bad design.
>
> It replaces an ugly chunk of ad-hoc code in tc-ppc.c.
Boils down to:
Simplified code + larger data structure
vs.
more complex code + smaller data structure.
I admit it's arguable in this case whether the simplification warrants
the extra data size. Note that at this stage we haven't actually
introduced any changes in assembler behaviour.
Alan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc64-linux infrastructure 5 of 6
2001-08-08 16:44 ` Alan Modra
@ 2001-08-09 12:55 ` Geoff Keating
2001-08-09 14:56 ` Alan Modra
0 siblings, 1 reply; 8+ messages in thread
From: Geoff Keating @ 2001-08-09 12:55 UTC (permalink / raw)
To: amodra; +Cc: tege, binutils
> Date: Thu, 9 Aug 2001 09:14:09 +0930
> From: Alan Modra <amodra@bigpond.net.au>
> Cc: Geoff Keating <geoffk@redhat.com>, binutils@sourceware.cygnus.com
> Mail-Followup-To: Torbjorn Granlund <tege@swox.com>,
> Geoff Keating <geoffk@redhat.com>, binutils@sourceware.cygnus.com
> Content-Disposition: inline
> User-Agent: Mutt/1.3.17i
>
> On Wed, Aug 08, 2001 at 10:55:37PM +0200, Torbjorn Granlund wrote:
> > Geoff Keating <geoffk@geoffk.org> writes:
> >
> > > Put relocs in the opcode table.
> >
> > This seems like a bad design.
> >
> > It replaces an ugly chunk of ad-hoc code in tc-ppc.c.
>
> Boils down to:
>
> Simplified code + larger data structure
> vs.
> more complex code + smaller data structure.
>
> I admit it's arguable in this case whether the simplification warrants
> the extra data size. Note that at this stage we haven't actually
> introduced any changes in assembler behaviour.
I think it's arguable that there is any simplification at all. The
code may be shorter, but not simpler, because now there is a blurring
of the boundary between the opcodes library (which is supposed to be
independent of the object file format) and BFD.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc64-linux infrastructure 5 of 6
2001-08-09 12:55 ` Geoff Keating
@ 2001-08-09 14:56 ` Alan Modra
2001-08-23 7:43 ` Torbjorn Granlund
0 siblings, 1 reply; 8+ messages in thread
From: Alan Modra @ 2001-08-09 14:56 UTC (permalink / raw)
To: Geoff Keating; +Cc: tege, binutils
On Thu, Aug 09, 2001 at 01:12:55PM -0700, Geoff Keating wrote:
>
> I think it's arguable that there is any simplification at all. The
> code may be shorter, but not simpler, because now there is a blurring
> of the boundary between the opcodes library (which is supposed to be
> independent of the object file format) and BFD.
You'd like the old code back? OK, can do it that way. I'll revert the
patch.
Alan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc64-linux infrastructure 5 of 6
2001-08-09 14:56 ` Alan Modra
@ 2001-08-23 7:43 ` Torbjorn Granlund
2001-08-23 18:30 ` Alan Modra
0 siblings, 1 reply; 8+ messages in thread
From: Torbjorn Granlund @ 2001-08-23 7:43 UTC (permalink / raw)
To: Alan Modra; +Cc: Geoff Keating, binutils
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
Alan Modra <amodra@bigpond.net.au> writes:
On Thu, Aug 09, 2001 at 01:12:55PM -0700, Geoff Keating wrote:
>
> I think it's arguable that there is any simplification at all. The
> code may be shorter, but not simpler, because now there is a blurring
> of the boundary between the opcodes library (which is supposed to be
> independent of the object file format) and BFD.
You'd like the old code back? OK, can do it that way. I'll revert the
patch.
What's the status of getting the powerpc64-linux patches into the repo?
Anything I need to do at this point?
--
Torbjörn
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc64-linux infrastructure 5 of 6
2001-08-23 7:43 ` Torbjorn Granlund
@ 2001-08-23 18:30 ` Alan Modra
0 siblings, 0 replies; 8+ messages in thread
From: Alan Modra @ 2001-08-23 18:30 UTC (permalink / raw)
To: Torbjorn Granlund; +Cc: Geoff Keating, binutils
On Thu, Aug 23, 2001 at 04:43:25PM +0200, Torbjorn Granlund wrote:
>
> What's the status of getting the powerpc64-linux patches into the repo?
I was intending to fix some of the problems (*) in elf64-ppc.c before
committing, but have been busy with other things. I'll probably end up
committing what I have at the moment, and tidy things up later.
> Anything I need to do at this point?
No.
--
Alan Modra
*) Shared libs, gc-sections. Garbage collection just about requires a
rewrite to do properly.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2001-08-23 18:30 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-08 6:19 powerpc64-linux infrastructure 5 of 6 Alan Modra
2001-08-08 13:47 ` Geoff Keating
2001-08-08 13:55 ` Torbjorn Granlund
2001-08-08 16:44 ` Alan Modra
2001-08-09 12:55 ` Geoff Keating
2001-08-09 14:56 ` Alan Modra
2001-08-23 7:43 ` Torbjorn Granlund
2001-08-23 18:30 ` Alan Modra
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).