https://sourceware.org/bugzilla/show_bug.cgi?id=26400
Jim Wilson <wilson at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilson at gcc dot gnu.org
--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
I had to read the gas docs to figure out what .offset does.
I see that frag_new calls frag_now_fix_octets, and that one has
if (now_seg == absolute_section)
return abs_section_offset;
which is not what the rest of the frag code is expecting. Not obvious what
that is for, or how that can work.
Though looking at tc-i386.c, in output_branch, I see it has
if (now_seg == absolute_section)
{
as_bad (_("relaxable branches not supported in absolute section"));
return;
}
and that tracks back to a patch a couple of months ago from Jan Beulich
https://sourceware.org/pipermail/binutils/2020-July/112420.html
This checks for the absolute section in various places, and increments the
absolute section offset instead of writing bytes to frags which is compatible
with what frag_now_fix_octets is doing.
It appears that significant changes are required to be able to support
instructions in the absolute section. And that the best we can do for
relaxable instructions is emit a polite error. Since we have a lot of
relaxable instructions this doesn't look very useful in general for RISC-V.
Unless you turn off relaxation, but you will lose code size and performance if
you do that.
The x86 port allows one to calculate the size of an insn via the absolute
section, but otherwise putting things in the absolute section isn't useful.
They won't appear in the output .o file for instance.
Why are you trying to put instructions in the absolute section? Maybe this did
something useful with very old a.out or coff targets, but not for ELF? You did
say the code was pretty old.
--
You are receiving this mail because:
You are on the CC list for the bug.
