* Re: Fun with binutils ...
@ 1997-07-18 15:20 ` Angus MacCuish
0 siblings, 0 replies; 6+ messages in thread
From: Angus MacCuish @ 1997-07-18 15:20 UTC (permalink / raw)
To: ralf, linux-mips; +Cc: linux-mips, linux
Please remove me from this mailing list.
Thanks,
Angus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Fun with binutils ...
@ 1997-07-15 19:35 Ralf Baechle
1997-07-15 19:48 ` David S. Miller
0 siblings, 1 reply; 6+ messages in thread
From: Ralf Baechle @ 1997-07-15 19:35 UTC (permalink / raw)
Cc: linux, linux-mips
Hi all,
after having found a couple of bugs in binutils 2.7 during the last
time I decided it'd about time to go for 2.8 instead of putting more
time into 2.7. Out of the frying pan into the fire ...
- binutils 2.8.0.13 still need the special patches to gas/config/tc-mips.c
to be applied. Otherwise they will reject the %HI, %hi and %lo
operators. Good so far, we never needed as few patches.
- since some pre-2.8 version binutils do optimize the case of the -N.
This helps to reduce the output filesize but somehow ld layouts
the segments wrong which results in a unuseable kernel. Removing
-N from the LDFLAGS in arch/mips/Makefile is a workaround.
- The %gp_rel() operator is not implemented in GAS. This means that
we cannot assemble PIC code with GAS that is produced by current
snapshots.
- ld spits messages about _gp_disp changing type. Dunno why yet.
- GAS still doesn't deal with _huge_ loops. The only program I know
of which is affected is lmbench, but that alone is reason enough
to fix it :-)
Ralf
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fun with binutils ...
1997-07-15 19:35 Ralf Baechle
@ 1997-07-15 19:48 ` David S. Miller
1997-07-15 22:15 ` Ralf Baechle
0 siblings, 1 reply; 6+ messages in thread
From: David S. Miller @ 1997-07-15 19:48 UTC (permalink / raw)
To: ralf; +Cc: linux, linux-mips
From: Ralf Baechle <ralf@mailhost.uni-koblenz.de>
Date: Tue, 15 Jul 1997 21:35:53 +0200 (MET DST)
- GAS still doesn't deal with _huge_ loops. The only program I know
of which is affected is lmbench, but that alone is reason enough
to fix it :-)
It is not a bug, just that we have the local label semantics specified
for linux-mips differently in gcc and gas. I fixed this ages ago and
it made lat_ctx.c compile just fine.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fun with binutils ...
@ 1997-07-15 22:15 ` Ralf Baechle
0 siblings, 0 replies; 6+ messages in thread
From: Ralf Baechle @ 1997-07-15 22:15 UTC (permalink / raw)
To: David S. Miller; +Cc: ralf, linux, linux-mips
> - GAS still doesn't deal with _huge_ loops. The only program I know
> of which is affected is lmbench, but that alone is reason enough
> to fix it :-)
>
> It is not a bug, just that we have the local label semantics specified
> for linux-mips differently in gcc and gas. I fixed this ages ago and
> it made lat_ctx.c compile just fine.
It has nothing to do with local label semantics of GCC; I can easily trigger
the problem in plain assembler using local or nonlocal labels. Maybe you
were still using a non-PIC lat_ctx at that time? The problem only affects
PIC. Another explanation would be that the size of the cacheflushing
loop in lmbench was somewhen increased or the GCC variant you used generates
different branches. The problematic GAS code from:
binutils/gas/config/tc-mips.c:
[...]
3439 case M_BGTL_I:
3440 likely = 1;
3441 case M_BGT_I:
[...]
3470 if (imm_expr.X_op != O_constant)
3471 as_bad ("Unsupported large constant");
[...]
3536 case M_BGTUL_I:
3537 likely = 1;
3538 case M_BGTU_I:
[...]
3544 if (imm_expr.X_op != O_constant)
3545 as_bad ("Unsupported large constant");
[...]
3632 case M_BLEL_I:
3633 likely = 1;
3634 case M_BLE_I:
[...]
3647 if (imm_expr.X_op != O_constant)
3648 as_bad ("Unsupported large constant");
[...]
3694 case M_BLEUL_I:
3695 likely = 1;
3696 case M_BLEU_I:
[...]
3702 if (imm_expr.X_op != O_constant)
3703 as_bad ("Unsupported large constant");
Ralf
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fun with binutils ...
@ 1997-07-15 22:15 ` Ralf Baechle
0 siblings, 0 replies; 6+ messages in thread
From: Ralf Baechle @ 1997-07-15 22:15 UTC (permalink / raw)
To: David S. Miller; +Cc: ralf, linux, linux-mips
> - GAS still doesn't deal with _huge_ loops. The only program I know
> of which is affected is lmbench, but that alone is reason enough
> to fix it :-)
>
> It is not a bug, just that we have the local label semantics specified
> for linux-mips differently in gcc and gas. I fixed this ages ago and
> it made lat_ctx.c compile just fine.
It has nothing to do with local label semantics of GCC; I can easily trigger
the problem in plain assembler using local or nonlocal labels. Maybe you
were still using a non-PIC lat_ctx at that time? The problem only affects
PIC. Another explanation would be that the size of the cacheflushing
loop in lmbench was somewhen increased or the GCC variant you used generates
different branches. The problematic GAS code from:
binutils/gas/config/tc-mips.c:
[...]
3439 case M_BGTL_I:
3440 likely = 1;
3441 case M_BGT_I:
[...]
3470 if (imm_expr.X_op != O_constant)
3471 as_bad ("Unsupported large constant");
[...]
3536 case M_BGTUL_I:
3537 likely = 1;
3538 case M_BGTU_I:
[...]
3544 if (imm_expr.X_op != O_constant)
3545 as_bad ("Unsupported large constant");
[...]
3632 case M_BLEL_I:
3633 likely = 1;
3634 case M_BLE_I:
[...]
3647 if (imm_expr.X_op != O_constant)
3648 as_bad ("Unsupported large constant");
[...]
3694 case M_BLEUL_I:
3695 likely = 1;
3696 case M_BLEU_I:
[...]
3702 if (imm_expr.X_op != O_constant)
3703 as_bad ("Unsupported large constant");
Ralf
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1997-07-18 15:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1997-07-18 15:20 Fun with binutils Angus MacCuish
1997-07-18 15:20 ` Angus MacCuish
-- strict thread matches above, loose matches on Subject: below --
1997-07-15 19:35 Ralf Baechle
1997-07-15 19:48 ` David S. Miller
1997-07-15 22:15 ` Ralf Baechle
1997-07-15 22:15 ` Ralf Baechle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.