On 3/6/25 3:07 PM, mzpqnxow via Gcc wrote:
Hello,
Direct questions listed at the end for the impatient :)
Hopefully my mail client wraps the text properly, if not, I apologize in
advance. I haven’t used this client for mailing list posts before…
I’m looking for information on GCC patch submission, hoping someone can
provide some guidance. Specifically, the formal or informal guidelines used
when determining if a specific submission is, in principle, something that
is welcomed, assuming it meets technical guidelines. I do not want to send
a patch if it won’t be considered as I don’t want to waste developers’ time
What I’m talking about: I would like to understand how open the project is
to accepting small patches that add support for a CPU (-mcpu targets) when
they’re very slight variations within a supported architecture
Why: I have the occasional need to have gcc emit MIPS1 instructions that do
not contain a subset of loads and stores (lwl/swl/lwr/swl instructions)
Context/History: There are several patches floating around that do this,
primarily from developers working on embedded networking development on a
few Realtek SoCs in the rtl819x family. These CPUs do not support these
instructions due to patent issues, and will SIGILL when encountering them.
I’m not aware of any work to contribute these upstream after a few quick
searches. There is extensive information available on OpenWRT [1]
Some specific questions:
1. Are any gcc mips experts aware of a way to accomplish what I described
above (no lwl/swl/lwr/swr instructions) *without* patching GCC? I have not
yet tested -mno-struct-align/-mstrict-align though they sound promising. I
plan to give them a try, it may render this all moot. I may be
misunderstanding precisely what they do
2. Are these sorts of patches (mcpu target, unpopular architecture)
generally considered currently?
3. If “it depends” - what are the primary considerations? Does the
popularity of the target factor into it? I admit that this CPU is not
popular and though it can still be found in embedded network devices, it is
only getting less common
4. If such a patch produces code that is inherently incompatible with glibc
(or some other core dependency of a common toolchain) is that considered a
blocker? What I’m referring to here is a (theoretical) example where glibc
uses the “bad” instructions in an asm block as part of some low-level
component (iirc, sigsetjmp, some of the loader functionality, etc. uses
hand-written asm)
I understand this is a pretty niche thing, only benefitting a subset of GCC
users, so I’m not expecting a lot of willingness to accept such a patch,
despite its relatively simplicity. I’m appreciative of any advice, guidance
or commentary the community has to offer, even if the answer is effectively
“don’t bother” :)
Thanks!
1. https://openwrt.org/docs/techref/hardware/soc/soc.realtek
I would generally expect/hope that such a patch would be relatively
simple to accept, given that, unless I am gravely wrong about the
meaning and functionality of the macro "ISA_HAS_LWL_LWR" in
gcc/config/mips/mips.h, it seems like a patch should not actually
involve much more than adjusting this macro (and adding some option for
the corresponding CPUs, as you mentioned).
