From: MegaIng <trampchamp@hotmail.de>
To: binutils@sourceware.org
Subject: Problems with relocations for a custom ISA
Date: Tue, 8 Aug 2023 01:08:49 +0200 [thread overview]
Message-ID: <DU0PR03MB972945947ABA24B8B484C16FA20CA@DU0PR03MB9729.eurprd03.prod.outlook.com> (raw)
Hello,
I am currently in the process of porting binutils to a custom
architecture I design with a few others (Spec [1], Start of our Port
[2]). An interesting quirk of this ISA is that its highly modular,
starting with fixed-size 16bit opcodes, but with extensions supporting
variable length instructions similar in power to what x86 has with it's
addressing modes. The base ISA is fixed 16bit word, but there are
extensions for 32 and 64bit words.
Most of the basics I already managed to implement, i.e. I can generate
simple workable ELF files. However, I am running into problems with
relocations for "load immediate" instructions. Without extensions, we
want to potentially emit long chains of instruction (3 to 8 instructions
is realistic), but with proper extensions in can get down to only 1
instruction of 3 or 4 bytes. I am unsure how to best represent such
variable length relocations in BFD and ELF. It seems like those always
assume fixed size relocations that get relaxed away in their entirety if
no longer needed. Is the best solution really to emit multiple
relocations and treat them as one in our custom
elf_relocate_sectionfunction?
In a similar vein I noticed that it seems impossible to teach
bfd_perform_relocation to correctly perform the non-trivial
transformation required to encode the signed offsets of jumps (since
they are non-consecutive bitfields), which means that we get garbage if
that function is called, for example when `--oformat` is not elf. Is
this really unavoidable? I tried using special_function, but since it's
also called from bfd_install_relocation, I couldn't figure out what the
correct behavior inside of it would be.
Thanks in advance,
MegaIng
1. https://github.com/ETC-A/etca-spec
2. https://github.com/ETC-A/etca-binutils-gdb
next reply other threads:[~2023-08-07 23:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 23:08 MegaIng [this message]
2023-08-08 14:13 ` Michael Matz
2023-08-08 14:35 ` MegaIng
2023-08-08 14:55 ` Xi Ruoyao
2023-08-08 15:35 ` Michael Matz
2023-08-08 17:26 ` MegaIng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DU0PR03MB972945947ABA24B8B484C16FA20CA@DU0PR03MB9729.eurprd03.prod.outlook.com \
--to=trampchamp@hotmail.de \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).