================
@@ -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:
Also tried to emphasise that we can basically decide overnight what "burden"
even means.
Which sounds awful said like that, but in reality it would be a few weeks of
debating the new requirements, giving people a chance to plan for it, a grace
period, then proposing removal, and so on.
I'm trying to write clearly even if it could be taken a bit harshly.
https://github.com/llvm/llvm-project/pull/207166
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
