================
@@ -0,0 +1,300 @@
+# Adding Target Support
+
+LLDB supports many combinations of architecture, operating system and other
+system components. In this document we describe the considerations and
+requirements for porting LLDB to a combination of those things which we will
+refer to as a "target" within this document.
+
+:::{note}
+The terms `Target` and `Platform` are used throughout LLDB, often
+referring to a subset of what this document calls a "target".
+Unfortunately there is no more specific word to use here.
+:::
+
+This document provides some hints on implementation, but because every target
+is unique, we expect developers to learn about implementation from existing
+targets.
+
+This document starts with the end of the process, proposing your target for
+upstream inclusion. It is worth reading through this even if that is not one of
+your goals, as you will have to tackle the same topics even in a downstream
+implementation.
+
+## Upstreaming Proposal Process
+
+You must send an RFC to the
+[LLDB Discourse forum](https://discourse.llvm.org/c/subprojects/lldb/8) before
+upstreaming new target support. This RFC must be accepted in some form by the
+community before any changes can be merged upstream that are specific to your
+target.
+
+This RFC follows the normal rules of the LLVM community decision making
process.
+
+We require an RFC for target support upstreaming because:
+* We want to ensure there is some level of public discussion on the topic.
+ It is important that details, even those obvious to the community at the
time,
+ are written down so that future readers may learn from them.
+* These discussions form the basis for future proposals and the assessment
+ of those proposals. Every proposal will be different in some way, and by
+ contrasting current proposals with the previous proposals we can do a better
+ job assessing them.
+
+RFCs are not required to be:
+* In a set format. Make a logical argument in whatever way you think fit.
+* Exhaustively detailed. Include what you think is relevant and the community
+ will ask for the rest.
+* Answering all the same questions, or making all the same points, as previous
+ proposals. Compare your target with existing targets, but not everything
will,
+ or has to, apply to yours.
+* A commitment to the maximum theoretical level of support (more on this
later).
+ If your resources are limited, say so, and that will be taken into account
+ (and vice versa, committing to a lot of work does not guarantee acceptance).
+
+## Removal Proposal Process
----------------
DavidSpickett wrote:
@JDevlieghere
> One suggestion I think is worth adding is that we "reserve the right" to
> change our mind. It's obvious, but I think it's worth calling out that if a
> target/platform becomes a burden, we can also do an RFC to remove it (usually
> conditioned on nobody stepping up to take on the responsibility).
I added this section to address this. It's pretty brief in the hopes that
people understand that you can use the same question prompts as for upstreaming.
But if there's anything specific you want to include let me know.
https://github.com/llvm/llvm-project/pull/207166
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
