Furquan Shaikh has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43603 )
Change subject: Documentation: Add documentation for resource allocator
......................................................................
Documentation: Add documentation for resource allocator
This change adds documentation for resource allocator in coreboot
which captures the expectations from device and platform drivers and
details about resource allocator v3 and v4.
Change-Id: I887284b44df2bf871f45c3a93fbef9cfc37e42a0
Signed-off-by: Furquan Shaikh <furquan(a)google.com>
---
A Documentation/device/index.md
A Documentation/device/resource_allocation.md
M Documentation/index.md
3 files changed, 95 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/03/43603/1
diff --git a/Documentation/device/index.md b/Documentation/device/index.md
new file mode 100644
index 0000000..9b703d6
--- /dev/null
+++ b/Documentation/device/index.md
@@ -0,0 +1,6 @@
+# Device management specific documentation
+
+This section contains documentation about device management in
+coreboot.
+
+- [Resource allocation](resource_allocation.md)
diff --git a/Documentation/device/resource_allocation.md b/Documentation/device/resource_allocation.md
new file mode 100644
index 0000000..e82b1c1
--- /dev/null
+++ b/Documentation/device/resource_allocation.md
@@ -0,0 +1,88 @@
+# Resource allocation in coreboot
+
+## Introduction
+
+Resource allocator in coreboot is responsible for assigning parts of the address space to devices. It handles two types of resource requests from devices viz. IO (IORESOURCE_IO) and MMIO (IORESOURCE_MEM). It is typically used for PCI devices, but it also keeps track of other assignments to ensure that there are no conflicts
+
+## Principles followed by the resource allocator
+
+Resource allocator follows these basic principles:
+
+* Allocate address space for every device resource as long as its requirement can be satisfied.
+* Don’t overlap with resources in fixed locations.
+* Don’t overlap with other resource allocations and follow the rules of bridges i.e. downstream devices of bridges should use parts of the address space allocated to the bridge.
+
+## Pre-allocation and post-allocation requirements
+
+The main function that is responsible for allocating resources is `allocate_resources()` and gets called in the `BS_DEV_RESOURCES` boot state. The resource allocator depends upon the device and platform drivers to perform pre-allocation and post-allocation operations. Pre-allocation step requires that the device and platform drivers provide a complete map of fixed resources (resources not changed by the allocator) owned by the device/platform and a list of resource requests that need to be satisfied by the allocator. This is done as part of the `read_resources()` device operation. This step is critical to ensure that the resource allocator can perform its operation correctly as per the principles outlined above. In the post-allocation step, the device and platform drivers are expected to assign the address space allocated by the allocator to the resources requested by the device. This is done as part of the `set_resources()` device operation. This allows the resource allocator to perform its operation independent of platform and device type.
+
+## Input and output rules for the resource allocator
+
+As mentioned above, the entrypoint into the resource allocator is `allocate_resources()`. One of the important goals of the allocator is to perform its operation independent of platform and device type. In order to accomplish this, it is important to clearly define what goes into the allocator and what comes out of it. This determines the expected behavior from the device and platform drivers.
+
+The allocator processes all devices in each domain sub-tree and performs allocation for resources of the following types:
+* IORESOURCE_IO
+* IORESOURCE_MEM
+
+On the other hand, it does not change resources marked with IORESOURCE_FIXED flag. These are referred to as “fixed resources”. Resources that have the IORESOURCE_BRIDGE flag set are referred to as “bridge resources”.
+
+
+### Input Rules
+
+1. IORESOURCE_IO and IORESOURCE_MEM are mutually exclusive. Both the flags must never be set for the same resource.
+1. Resources that should not be changed by the allocator must be marked with IORESOURCE_FIXED flag. These resources must be pre-assigned a valid `base` address. It is used by the allocator to ensure there are no conflicts during the allocation step.
+1. A fixed resource must not overlap with any other fixed resource within the same address space (IO / MEM), unless either of them is a bridge resource.
+1. A fixed bridge resource must not overlap with any other fixed resource within the same address space and on the same bus (i.e. same device or its siblings), unless exactly one of them has IORESOURCE_SUBTRACTIVE set.
+
+### Output Rules
+
+1. All device attributes (members of `struct device` structure) beside non-fixed resources are left unaltered.
+1. The structure of resource lists (`next` pointers) is left unaltered.
+1. The `index` and `gran` attributes of all resources are left unaltered.
+1. The `size`, `limit` and `align` attributes of all non-bridge resources are left unaltered.
+1. All non-fixed assigned resources downstream of a bridge are covered by an assigned bridge resource of that bridge.
+1. IORESOURCE_ASSIGNED flag is set for a non-fixed resource only if it is assigned address space by the allocator. If allocation for a non-fixed resource fails for any reason, all the attributes of that resource are left untouched including resource flags. It is the responsibility of the device and platform driver to check the IORESOURCE_ASSIGNED flag before using the values stored in the `base` field of the resource.
+
+## Resource allocator implementations
+
+Currently, there are two flavors of resource allocators implemented in coreboot - v3 and v4.
+
+### Resource Allocator v3
+
+This is the older resource allocator which is used only on the following platforms:
+
+* northbridge/amd/pi/00630F01
+* northbridge/amd/pi/00730F01
+* northbridge/amd/pi/00660F01
+* northbridge/amd/agesa/family14
+* northbridge/amd/agesa/family15tn
+* northbridge/amd/agesa/family16kb
+
+Resource allocator v3 is still retained and used for the above platforms because these platforms do not conform to the requirements of the allocator i.e. not all the fixed resources of the platform are provided during the `read_resources()` operation. This results in the resource allocator not getting a complete view of the address space. These platforms still work okay with the older resource allocator because of the way it performs allocation in a single window of the address space. No platform other than the ones listed above must use resource allocator v3 as it will be deprecated once the above platforms are fixed. It can be enabled by selecting the `RESOURCE_ALLOCATOR_V3` Kconfig option.
+
+#### Highlights
+
+* Contains two phases - resource computation phase and resource allocation phase.
+* Finds a single window for resource allocation towards the top of addressable memory under 4G boundary.
+
+#### Limitations
+
+* Finds a single window for resource allocation towards the top of addressable memory under 4G boundary.
+* Does not support allocation above 4G boundary. Thus, it might not be able to allocate resources for devices that request large allocations (e.g. USB4, discrete graphics, etc.).
+
+
+### Resource Allocator v4
+
+This is the latest resource allocator that uses multiple ranges for allocating resources. Unlike resource allocator v3, it does not use the topmost available window for allocation. Instead, it uses the first available window within the address space that is available and satisfies the resource request. This allows utilization of the entire available address space and also allows allocation above the 4G boundary.
+
+#### Highlights
+
+* Contains two phases - resource computation phase and resource allocation phase.
+* In phase 1, the allocator walks in a DFS fashion gathering the requirements from leaf devices and propagates them back up to their upstream bridges until the requirements for all the downstream devices of the domain are gathered.
+* Every domain is considered to have a fixed set of resources. These ranges cannot be relaxed based on the requirements of the downstream devices. They represent the available windows from which resources can be allocated to the different devices under the domain.
+* In the second phase, the allocator walks down the tree allocating resources to downstream devices as per the resource requirements gathered in the first phase.
+* In order to accomplish best fit for the resources, a list of ranges is maintained by each resource type (IO and MEM).
+* Domain does not distinguish between mem and prefmem resources. Thus, the resource allocation at domain level considers mem and prefmem together when finding the best fit based on the biggest resource requirement.
+* Allocation at bridge level works the same as at the domain level. One major difference at the bridge level is that it considers prefmem resources separately from mem resources.
+* Device and platform drivers can request the allocator to perform allocation for a particular resource above 4G boundary by using the flag `IORESOURCE_ABOVE_4G`.
+
diff --git a/Documentation/index.md b/Documentation/index.md
index a7c4869..ec26b4e 100644
--- a/Documentation/index.md
+++ b/Documentation/index.md
@@ -188,3 +188,4 @@
* [Utilities](util.md)
* [Release notes for past releases](releases/index.md)
* [Flashing firmware tutorial](flash_tutorial/index.md)
+* [Device Management](device/index.md)
--
To view, visit https://review.coreboot.org/c/coreboot/+/43603
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I887284b44df2bf871f45c3a93fbef9cfc37e42a0
Gerrit-Change-Number: 43603
Gerrit-PatchSet: 1
Gerrit-Owner: Furquan Shaikh <furquan(a)google.com>
Gerrit-MessageType: newchange
Hello Iru Cai,
I'd like you to do a code review. Please visit
https://review.coreboot.org/c/coreboot/+/42159
to review the following change.
Change subject: crossgcc: Update to GCC 8.4.0
......................................................................
crossgcc: Update to GCC 8.4.0
- Remove gnat-bad_constant.patch which is already in GCC 8.4.0
- Backport GNAT exception handler v1
Change-Id: Icfc8430764404a6c272deb490fee23c963bd7ee5
Signed-off-by: Iru Cai <mytbk920423(a)gmail.com>
---
M util/crossgcc/buildgcc
D util/crossgcc/patches/gcc-8.3.0_gnat-bad_constant.patch
R util/crossgcc/patches/gcc-8.4.0_ada-musl_workaround.patch
R util/crossgcc/patches/gcc-8.4.0_gnat.patch
A util/crossgcc/patches/gcc-8.4.0_gnat_eh.patch
R util/crossgcc/patches/gcc-8.4.0_libgcc.patch
R util/crossgcc/patches/gcc-8.4.0_nds32_ite.patch
D util/crossgcc/sum/gcc-8.3.0.tar.xz.cksum
A util/crossgcc/sum/gcc-8.4.0.tar.xz.cksum
9 files changed, 272 insertions(+), 152 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/59/42159/1
diff --git a/util/crossgcc/buildgcc b/util/crossgcc/buildgcc
index 8770e02..e0827e0 100755
--- a/util/crossgcc/buildgcc
+++ b/util/crossgcc/buildgcc
@@ -36,7 +36,7 @@
GMP_VERSION=6.1.2
MPFR_VERSION=4.0.2
MPC_VERSION=1.1.0
-GCC_VERSION=8.3.0
+GCC_VERSION=8.4.0
GCC_AUTOCONF_VERSION=2.69
BINUTILS_VERSION=2.33.1
GDB_VERSION=8.3.1
diff --git a/util/crossgcc/patches/gcc-8.3.0_gnat-bad_constant.patch b/util/crossgcc/patches/gcc-8.3.0_gnat-bad_constant.patch
deleted file mode 100644
index e98f933..0000000
--- a/util/crossgcc/patches/gcc-8.3.0_gnat-bad_constant.patch
+++ /dev/null
@@ -1,150 +0,0 @@
-commit b6f742f96c62bab0582021455328ae3be58e16d3
-Author: pmderodat <pmderodat@138bc75d-0d04-0410-961f-82ee72b054a4>
-Date: Fri May 25 09:05:10 2018 +0000
-
- [Ada] Remove "constant" attribute on Osint.Unknown_Attributes
-
- 2018-05-25 Arnaud Charlet <charlet(a)adacore.com>
-
- gcc/ada/
-
- * exp_aggr.adb (Convert_To_Positional): Bump default for
- Max_Others_Replicate to 32. Update comments.
- * osint.ads (Unknown_Attributes): No longer pretend this is a constant.
- (No_File_Info_Cache): Initialize separately.
- * osint.adb (No_File_Info_Cache): Update initializer.
-
- git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@260739 138bc75d-0d04-0410-961f-82ee72b054a4
-
-diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog
-index e4127e472aa..d56240b7b82 100644
---- a/gcc/ada/ChangeLog
-+++ b/gcc/ada/ChangeLog
-@@ -188,6 +188,14 @@
- an allocator if the type is an unconstrained record type with default
- discriminant.
-
-+2018-05-25 Arnaud Charlet <charlet(a)adacore.com>
-+
-+ * exp_aggr.adb (Convert_To_Positional): Bump default for
-+ Max_Others_Replicate to 32. Update comments.
-+ * osint.ads (Unknown_Attributes): No longer pretend this is a constant.
-+ (No_File_Info_Cache): Initialize separately.
-+ * osint.adb (No_File_Info_Cache): Update initializer.
-+
- 2018-05-04 John Marino <gnugcc(a)marino.st>
-
- PR ada/85635
-diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
-index f723c1b4d99..ff5210eb4e4 100644
---- a/gcc/ada/exp_aggr.adb
-+++ b/gcc/ada/exp_aggr.adb
-@@ -284,14 +284,14 @@ package body Exp_Aggr is
-
- procedure Convert_To_Positional
- (N : Node_Id;
-- Max_Others_Replicate : Nat := 5;
-+ Max_Others_Replicate : Nat := 32;
- Handle_Bit_Packed : Boolean := False);
- -- If possible, convert named notation to positional notation. This
- -- conversion is possible only in some static cases. If the conversion is
- -- possible, then N is rewritten with the analyzed converted aggregate.
- -- The parameter Max_Others_Replicate controls the maximum number of
- -- values corresponding to an others choice that will be converted to
-- -- positional notation (the default of 5 is the normal limit, and reflects
-+ -- positional notation (the default of 32 is the normal limit, and reflects
- -- the fact that normally the loop is better than a lot of separate
- -- assignments). Note that this limit gets overridden in any case if
- -- either of the restrictions No_Elaboration_Code or No_Implicit_Loops is
-@@ -301,11 +301,6 @@ package body Exp_Aggr is
- -- Packed_Array_Aggregate_Handled, we set this parameter to True, since
- -- these are cases we handle in there.
-
-- -- It would seem useful to have a higher default for Max_Others_Replicate,
-- -- but aggregates in the compiler make this impossible: the compiler
-- -- bootstrap fails if Max_Others_Replicate is greater than 25. This
-- -- is unexpected ???
--
- procedure Expand_Array_Aggregate (N : Node_Id);
- -- This is the top-level routine to perform array aggregate expansion.
- -- N is the N_Aggregate node to be expanded.
-@@ -4292,7 +4287,7 @@ package body Exp_Aggr is
-
- procedure Convert_To_Positional
- (N : Node_Id;
-- Max_Others_Replicate : Nat := 5;
-+ Max_Others_Replicate : Nat := 32;
- Handle_Bit_Packed : Boolean := False)
- is
- Typ : constant Entity_Id := Etype (N);
-diff --git a/gcc/ada/osint.adb b/gcc/ada/osint.adb
-index 0c23761b6dc..896fbc7ee37 100644
---- a/gcc/ada/osint.adb
-+++ b/gcc/ada/osint.adb
-@@ -250,8 +250,7 @@ package body Osint is
- Attr : aliased File_Attributes;
- end record;
-
-- No_File_Info_Cache : constant File_Info_Cache :=
-- (No_File, Unknown_Attributes);
-+ No_File_Info_Cache : constant File_Info_Cache := (No_File, (others => 0));
-
- package File_Name_Hash_Table is new GNAT.HTable.Simple_HTable (
- Header_Num => File_Hash_Num,
-diff --git a/gcc/ada/osint.ads b/gcc/ada/osint.ads
-index 65a87fe4ce3..6c75b521456 100644
---- a/gcc/ada/osint.ads
-+++ b/gcc/ada/osint.ads
-@@ -255,10 +255,26 @@ package Osint is
- -- from the disk and then cached in the File_Attributes parameter (possibly
- -- along with other values).
-
-- type File_Attributes is private;
-- Unknown_Attributes : constant File_Attributes;
-+ File_Attributes_Size : constant Natural := 32;
-+ -- This should be big enough to fit a "struct file_attributes" on any
-+ -- system. It doesn't cause any malfunction if it is too big (which avoids
-+ -- the need for either mapping the struct exactly or importing the sizeof
-+ -- from C, which would result in dynamic code). However, it does waste
-+ -- space (e.g. when a component of this type appears in a record, if it is
-+ -- unnecessarily large). Note: for runtime units, use System.OS_Constants.
-+ -- SIZEOF_struct_file_attributes instead, which has the exact value.
-+
-+ type File_Attributes is
-+ array (1 .. File_Attributes_Size)
-+ of System.Storage_Elements.Storage_Element;
-+ for File_Attributes'Alignment use Standard'Maximum_Alignment;
-+
-+ Unknown_Attributes : File_Attributes;
- -- A cache for various attributes for a file (length, accessibility,...)
-- -- This must be initialized to Unknown_Attributes prior to the first call.
-+ -- Will be initialized properly at elaboration (for efficiency later on,
-+ -- avoid function calls every time we want to reset the attributes) prior
-+ -- to the first usage. We cannot make it constant since the compiler may
-+ -- put it in a read-only section.
-
- function Is_Directory
- (Name : C_File_Name;
-@@ -754,22 +770,4 @@ private
- -- detected, the file being written is deleted, and a fatal error is
- -- signalled.
-
-- File_Attributes_Size : constant Natural := 32;
-- -- This should be big enough to fit a "struct file_attributes" on any
-- -- system. It doesn't cause any malfunction if it is too big (which avoids
-- -- the need for either mapping the struct exactly or importing the sizeof
-- -- from C, which would result in dynamic code). However, it does waste
-- -- space (e.g. when a component of this type appears in a record, if it is
-- -- unnecessarily large). Note: for runtime units, use System.OS_Constants.
-- -- SIZEOF_struct_file_attributes instead, which has the exact value.
--
-- type File_Attributes is
-- array (1 .. File_Attributes_Size)
-- of System.Storage_Elements.Storage_Element;
-- for File_Attributes'Alignment use Standard'Maximum_Alignment;
--
-- Unknown_Attributes : constant File_Attributes := (others => 0);
-- -- Will be initialized properly at elaboration (for efficiency later on,
-- -- avoid function calls every time we want to reset the attributes).
--
- end Osint;
diff --git a/util/crossgcc/patches/gcc-8.3.0_ada-musl_workaround.patch b/util/crossgcc/patches/gcc-8.4.0_ada-musl_workaround.patch
similarity index 100%
rename from util/crossgcc/patches/gcc-8.3.0_ada-musl_workaround.patch
rename to util/crossgcc/patches/gcc-8.4.0_ada-musl_workaround.patch
diff --git a/util/crossgcc/patches/gcc-8.3.0_gnat.patch b/util/crossgcc/patches/gcc-8.4.0_gnat.patch
similarity index 100%
rename from util/crossgcc/patches/gcc-8.3.0_gnat.patch
rename to util/crossgcc/patches/gcc-8.4.0_gnat.patch
diff --git a/util/crossgcc/patches/gcc-8.4.0_gnat_eh.patch b/util/crossgcc/patches/gcc-8.4.0_gnat_eh.patch
new file mode 100644
index 0000000..151a3e6
--- /dev/null
+++ b/util/crossgcc/patches/gcc-8.4.0_gnat_eh.patch
@@ -0,0 +1,270 @@
+commit 5d733372faa97c1c3943a20a252d000db37c738b
+Author: Alexandre Oliva <oliva(a)adacore.com>
+Date: Fri Aug 2 18:46:51 2019 +0000
+
+ rework Ada EH Machine_Occurrence deallocation
+
+ Introduce exception handler ABI #1 to ensure single release, no access
+ after release of reraised Machine_Occurrences, and no failure to
+ re-reraise a Machine_Occurrence.
+
+ Unlike Ada exceptions, foreign exceptions do not get a new
+ Machine_Occurrence upon reraise, but each handler would delete the
+ exception upon completion, normal or exceptional, save for the case of
+ a 'raise;' statement within the handler, that avoided the delete by
+ clearing the exception pointer that the cleanup would use to release
+ it. The cleared exception pointer might then be used by a subsequent
+ reraise within the same handler. Get_Current_Excep.all would also
+ expose the Machine_Occurrence to reuse by Reraise_Occurrence, even for
+ native exceptions.
+
+ Under ABI #1, Begin_Handler_v1 claims responsibility for releasing an
+ exception by saving its cleanup and setting it to Claimed_Cleanup.
+ End_Handler_v1 restores the cleanup and runs it, as long as it isn't
+ still Claimed_Cleanup (which indicates an enclosing handler has
+ already claimed responsibility for releasing it), and as long as the
+ same exception is not being propagated up (the next handler of the
+ propagating exception will then claim responsibility for releasing
+ it), so reraise no longer needs to clear the exception pointer, and it
+ can just propagate the exception, just like Reraise_Occurrence.
+
+ ABI #1 is fully interoperable with ABI #0, i.e., exception handlers
+ that call the #0 primitives can be linked together with ones that call
+ the #1 primitives, and they will not misbehave. When a #1 handler
+ claims responsibility for releasing an exception, even #0 reraises
+ dynamically nested within it will refrain from releasing it. However,
+ when a #0 handler is a handler of a foreign exception that would have
+ been responsible for releasing it with #1, a Reraise_Occurrence of
+ that foreign or other Machine_Occurrence-carrying exception may still
+ cause the exception to be released multiple times, and to be used
+ after it is first released, even if other handlers of the foreign
+ exception use #1.
+
+
+ for gcc/ada/ChangeLog
+
+ * libgnat/a-exexpr.adb (Begin_Handler_v1, End_Handler_v1): New.
+ (Claimed_Cleanup): New.
+ (Begin_Handler, End_Handler): Document.
+ * gcc-interface/trans.c (gigi): Switch to exception handler
+ ABI #1.
+ (Exception_Handler_to_gnu_gcc): Save the original cleanup
+ returned by begin handler, pass it to end handler, and use
+ EH_ELSE_EXPR to pass a propagating exception to end handler.
+ (gnat_to_gnu): Leave the exception pointer alone for reraise.
+ (add_cleanup): Handle EH_ELSE_EXPR, require it by itself.
+
+ From-SVN: r274029
+
+diff --git a/gcc/ada/libgnat/a-exexpr.adb b/gcc/ada/libgnat/a-exexpr.adb
+index b1aa1c6e6ba..5e72fd6e3f2 100644
+--- a/gcc/ada/libgnat/a-exexpr.adb
++++ b/gcc/ada/libgnat/a-exexpr.adb
+@@ -197,15 +197,75 @@ package body Exception_Propagation is
+ -- whose machine occurrence is Mo. The message is empty, the backtrace
+ -- is empty too and the exception identity is Foreign_Exception.
+
+- -- Hooks called when entering/leaving an exception handler for a given
+- -- occurrence, aimed at handling the stack of active occurrences. The
+- -- calls are generated by gigi in tree_transform/N_Exception_Handler.
++ -- Hooks called when entering/leaving an exception handler for a
++ -- given occurrence. The calls are generated by gigi in
++ -- Exception_Handler_to_gnu_gcc.
++
++ -- Begin_Handler_v1, called when entering an exception handler,
++ -- claims responsibility for the handler to release the
++ -- GCC_Exception occurrence. End_Handler_v1, called when
++ -- leaving the handler, releases the occurrence, unless the
++ -- occurrence is propagating further up, or the handler is
++ -- dynamically nested in the context of another handler that
++ -- claimed responsibility for releasing that occurrence.
++
++ -- Responsibility is claimed by changing the Cleanup field to
++ -- Claimed_Cleanup, which enables claimed exceptions to be
++ -- recognized, and avoids accidental releases even by foreign
++ -- handlers.
++
++ function Begin_Handler_v1
++ (GCC_Exception : not null GCC_Exception_Access)
++ return System.Address;
++ pragma Export (C, Begin_Handler_v1, "__gnat_begin_handler_v1");
++ -- Called when entering an exception handler. Claim
++ -- responsibility for releasing GCC_Exception, by setting the
++ -- cleanup/release function to Claimed_Cleanup, and return the
++ -- address of the previous cleanup/release function.
++
++ procedure End_Handler_v1
++ (GCC_Exception : not null GCC_Exception_Access;
++ Saved_Cleanup : System.Address;
++ Propagating_Exception : GCC_Exception_Access);
++ pragma Export (C, End_Handler_v1, "__gnat_end_handler_v1");
++ -- Called when leaving an exception handler. Restore the
++ -- Saved_Cleanup in the GCC_Exception occurrence, and then release
++ -- it, unless it remains claimed by an enclosing handler, or
++ -- GCC_Exception and Propagating_Exception are the same
++ -- occurrence. Propagating_Exception could be either an
++ -- occurrence (re)raised within the handler of GCC_Exception, when
++ -- we're executing as an exceptional cleanup, or null, if we're
++ -- completing the handler of GCC_Exception normally.
++
++ procedure Claimed_Cleanup
++ (Reason : Unwind_Reason_Code;
++ GCC_Exception : not null GCC_Exception_Access);
++ pragma Export (C, Claimed_Cleanup, "__gnat_claimed_cleanup");
++ -- A do-nothing placeholder installed as GCC_Exception.Cleanup
++ -- while handling GCC_Exception, to claim responsibility for
++ -- releasing it, and to stop it from being accidentally released.
++
++ -- The following are version 0 implementations of the version 1
++ -- hooks above. They remain in place for compatibility with the
++ -- output of compilers that still use version 0, such as those
++ -- used during bootstrap. They are interoperable with the v1
++ -- hooks, except that the older versions may malfunction when
++ -- handling foreign exceptions passed to Reraise_Occurrence.
+
+ procedure Begin_Handler (GCC_Exception : not null GCC_Exception_Access);
+ pragma Export (C, Begin_Handler, "__gnat_begin_handler");
++ -- Called when entering an exception handler translated by an old
++ -- compiler. It does nothing.
+
+ procedure End_Handler (GCC_Exception : GCC_Exception_Access);
+ pragma Export (C, End_Handler, "__gnat_end_handler");
++ -- Called when leaving an exception handler translated by an old
++ -- compiler. It releases GCC_Exception, unless it is null. It is
++ -- only ever null when the handler has a 'raise;' translated by a
++ -- v0-using compiler. The artificial handler variable passed to
++ -- End_Handler was set to null to tell End_Handler to refrain from
++ -- releasing the reraised exception. In v1 safer ways are used to
++ -- accomplish that.
+
+ --------------------------------------------------------------------
+ -- Accessors to Basic Components of a GNAT Exception Data Pointer --
+@@ -352,6 +412,128 @@ package body Exception_Propagation is
+ end if;
+ end Setup_Current_Excep;
+
++ ----------------------
++ -- Begin_Handler_v1 --
++ ----------------------
++
++ function Begin_Handler_v1
++ (GCC_Exception : not null GCC_Exception_Access)
++ return System.Address is
++ Saved_Cleanup : constant System.Address := GCC_Exception.Cleanup;
++ begin
++ -- Claim responsibility for releasing this exception, and stop
++ -- others from releasing it.
++ GCC_Exception.Cleanup := Claimed_Cleanup'Address;
++ return Saved_Cleanup;
++ end Begin_Handler_v1;
++
++ --------------------
++ -- End_Handler_v1 --
++ --------------------
++
++ procedure End_Handler_v1
++ (GCC_Exception : not null GCC_Exception_Access;
++ Saved_Cleanup : System.Address;
++ Propagating_Exception : GCC_Exception_Access) is
++ begin
++ GCC_Exception.Cleanup := Saved_Cleanup;
++ -- Restore the Saved_Cleanup, so that it is either used to
++ -- release GCC_Exception below, or transferred to the next
++ -- handler of the Propagating_Exception occurrence. The
++ -- following test ensures that an occurrence is only released
++ -- once, even after reraises.
++ --
++ -- The idea is that the GCC_Exception is not to be released
++ -- unless it had an unclaimed Cleanup when the handler started
++ -- (see Begin_Handler_v1 above), but if we propagate across its
++ -- handler a reraise of the same exception, we transfer to the
++ -- Propagating_Exception the responsibility for running the
++ -- Saved_Cleanup when its handler completes.
++ --
++ -- This ownership transfer mechanism ensures safety, as in
++ -- single release and no dangling pointers, because there is no
++ -- way to hold on to the Machine_Occurrence of an
++ -- Exception_Occurrence: the only situations in which another
++ -- Exception_Occurrence gets the same Machine_Occurrence are
++ -- through Reraise_Occurrence, and plain reraise, and so we
++ -- have the following possibilities:
++ --
++ -- - Reraise_Occurrence is handled within the running handler,
++ -- and so when completing the dynamically nested handler, we
++ -- must NOT release the exception. A Claimed_Cleanup upon
++ -- entry of the nested handler, installed when entering the
++ -- enclosing handler, ensures the exception will not be
++ -- released by the nested handler, but rather by the enclosing
++ -- handler.
++ --
++ -- - Reraise_Occurrence/reraise escapes the running handler,
++ -- and we run as an exceptional cleanup for GCC_Exception. The
++ -- Saved_Cleanup was reinstalled, but since we're propagating
++ -- the same machine occurrence, we do not release it. Instead,
++ -- we transfer responsibility for releasing it to the eventual
++ -- handler of the propagating exception.
++ --
++ -- - An unrelated exception propagates through the running
++ -- handler. We restored GCC_Exception.Saved_Cleanup above.
++ -- Since we're propagating a different exception, we proceed to
++ -- release GCC_Exception, unless Saved_Cleanup was
++ -- Claimed_Cleanup, because then we know we're not in the
++ -- outermost handler for GCC_Exception.
++ --
++ -- - The handler completes normally, so it reinstalls the
++ -- Saved_Cleanup and runs it, unless it was Claimed_Cleanup.
++ -- If Saved_Cleanup is null, Unwind_DeleteException (currently)
++ -- has no effect, so we could skip it, but if it is ever
++ -- changed to do more in this case, we're ready for that,
++ -- calling it exactly once.
++ if Saved_Cleanup /= Claimed_Cleanup'Address
++ and then
++ Propagating_Exception /= GCC_Exception
++ then
++ declare
++ Current : constant EOA := Get_Current_Excep.all;
++ Cur_Occ : constant GCC_Exception_Access
++ := To_GCC_Exception (Current.Machine_Occurrence);
++ begin
++ -- If we are releasing the Machine_Occurrence of the current
++ -- exception, reset the access to it, so that it is no
++ -- longer accessible.
++ if Cur_Occ = GCC_Exception then
++ Current.Machine_Occurrence := System.Null_Address;
++ end if;
++ end;
++ Unwind_DeleteException (GCC_Exception);
++ end if;
++ end End_Handler_v1;
++
++ ---------------------
++ -- Claimed_Cleanup --
++ ---------------------
++
++ procedure Claimed_Cleanup
++ (Reason : Unwind_Reason_Code;
++ GCC_Exception : not null GCC_Exception_Access) is
++ pragma Unreferenced (Reason);
++ pragma Unreferenced (GCC_Exception);
++ begin
++ -- This procedure should never run. If it does, it's either a
++ -- version 0 handler or a foreign handler, attempting to
++ -- release an exception while a version 1 handler that claimed
++ -- responsibility for releasing the exception remains still
++ -- active. This placeholder stops GCC_Exception from being
++ -- released by them.
++
++ -- We could get away with just Null_Address instead, with
++ -- nearly the same effect, but with this placeholder we can
++ -- detect and report unexpected releases, and we can tell apart
++ -- a GCC_Exception without a Cleanup, from one with another
++ -- active handler, so as to still call Unwind_DeleteException
++ -- exactly once: currently, Unwind_DeleteException does nothing
++ -- when the Cleanup is null, but should it ever be changed to
++ -- do more, we'll still be safe.
++ null;
++ end Claimed_Cleanup;
++
+ -------------------
+ -- Begin_Handler --
+ -------------------
diff --git a/util/crossgcc/patches/gcc-8.3.0_libgcc.patch b/util/crossgcc/patches/gcc-8.4.0_libgcc.patch
similarity index 100%
rename from util/crossgcc/patches/gcc-8.3.0_libgcc.patch
rename to util/crossgcc/patches/gcc-8.4.0_libgcc.patch
diff --git a/util/crossgcc/patches/gcc-8.3.0_nds32_ite.patch b/util/crossgcc/patches/gcc-8.4.0_nds32_ite.patch
similarity index 100%
rename from util/crossgcc/patches/gcc-8.3.0_nds32_ite.patch
rename to util/crossgcc/patches/gcc-8.4.0_nds32_ite.patch
diff --git a/util/crossgcc/sum/gcc-8.3.0.tar.xz.cksum b/util/crossgcc/sum/gcc-8.3.0.tar.xz.cksum
deleted file mode 100644
index b46ef8c..0000000
--- a/util/crossgcc/sum/gcc-8.3.0.tar.xz.cksum
+++ /dev/null
@@ -1 +0,0 @@
-c27f4499dd263fe4fb01bcc5565917f3698583b2 tarballs/gcc-8.3.0.tar.xz
diff --git a/util/crossgcc/sum/gcc-8.4.0.tar.xz.cksum b/util/crossgcc/sum/gcc-8.4.0.tar.xz.cksum
new file mode 100644
index 0000000..441f096
--- /dev/null
+++ b/util/crossgcc/sum/gcc-8.4.0.tar.xz.cksum
@@ -0,0 +1 @@
+00ddb177b04caffd40f7af0175d5b3c8e5442545 tarballs/gcc-8.4.0.tar.xz
--
To view, visit https://review.coreboot.org/c/coreboot/+/42159
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Icfc8430764404a6c272deb490fee23c963bd7ee5
Gerrit-Change-Number: 42159
Gerrit-PatchSet: 1
Gerrit-Owner: Iru Cai (vimacs) <mytbk920423(a)gmail.com>
Gerrit-Reviewer: Iru Cai <mytbk920423(a)gmail.com>
Gerrit-MessageType: newchange