This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Fold arithmetic integer expressions
- From: Alan Modra <amodra at gmail dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- Cc: Tristan Gingold <gingold at adacore dot com>, binutils <binutils at sourceware dot org>
- Date: Tue, 4 Oct 2016 10:49:43 +1030
- Subject: Fold arithmetic integer expressions
- Authentication-results: sourceware.org; auth=none
- References: <F8E6EE0B-49F3-4986-B48E-45AD57BD0D7C@adacore.com> <20160719010211.GT1256@bubble.grove.modra.org> <DE7B211B-4922-4F8A-AF0D-E11B2ECBB5EC@adacore.com> <20160719083907.GV1256@bubble.grove.modra.org> <D2BAEB3D-9819-47B0-AA16-8F3A9527C890@adacore.com> <20160719113807.GW1256@bubble.grove.modra.org> <20160720024436.GA1256@bubble.grove.modra.org> <57ED173A.6000207@foss.arm.com> <20160930163422.GN4877@bubble.grove.modra.org>
Commit b751e639 regressed arm linux kernel builds, that have an
ASSERT (((__hyp_idmap_text_end - (__hyp_idmap_text_start
& ~ (((0x1 << 0xc) - 0x1))))
<= (0x1 << 0xc)), HYP init code too big or misaligned)
Due to some insanity in ld expression evaluation, the integer values
0x1 and 0xc above are treated as absolute addresses (ie. they have an
associated section, *ABS*, see exp_fold_tree_1 case etree_value) while
the expression (0x1 << 0xc) has a plain number result. The left hand
side of the inequality happens to evaluate to a "negative" .text
section relative value. Comparing a section relative value against an
absolute value works since the section relative value is first
converted to absolute. Comparing a section relative value against a
number just compares the offsets, which fails since the "negative"
offset is really a very large positive number.
This patch works around the problem by folding integer expressions, so
the assert again becomes
ASSERT (((__hyp_idmap_text_end - (__hyp_idmap_text_start
& 0xfffffffffffff000))
<= 0x1000), HYP init code too big or misaligned)
* ldexp.c (exp_value_fold): New function.
(exp_unop, exp_binop, exp_trinop): Use it.
diff --git a/ld/ldexp.c b/ld/ldexp.c
index a560643..9f88144 100644
--- a/ld/ldexp.c
+++ b/ld/ldexp.c
@@ -1252,6 +1252,19 @@ exp_fold_tree_no_dot (etree_type *tree)
exp_fold_tree_1 (tree);
}
+static void
+exp_value_fold (etree_type *tree)
+{
+ exp_fold_tree_no_dot (tree);
+ if (expld.result.valid_p)
+ {
+ tree->type.node_code = INT;
+ tree->value.value = expld.result.value;
+ tree->value.str = NULL;
+ tree->type.node_class = etree_value;
+ }
+}
+
etree_type *
exp_binop (int code, etree_type *lhs, etree_type *rhs)
{
@@ -1263,6 +1276,12 @@ exp_binop (int code, etree_type *lhs, etree_type *rhs)
new_e->binary.lhs = lhs;
new_e->binary.rhs = rhs;
new_e->type.node_class = etree_binary;
+ if (lhs->type.node_class == etree_value
+ && rhs->type.node_class == etree_value
+ && code != ALIGN_K
+ && code != DATA_SEGMENT_ALIGN
+ && code != DATA_SEGMENT_RELRO_END)
+ exp_value_fold (new_e);
return new_e;
}
@@ -1278,6 +1297,10 @@ exp_trinop (int code, etree_type *cond, etree_type *lhs, etree_type *rhs)
new_e->trinary.cond = cond;
new_e->trinary.rhs = rhs;
new_e->type.node_class = etree_trinary;
+ if (cond->type.node_class == etree_value
+ && lhs->type.node_class == etree_value
+ && rhs->type.node_class == etree_value)
+ exp_value_fold (new_e);
return new_e;
}
@@ -1291,6 +1314,12 @@ exp_unop (int code, etree_type *child)
new_e->unary.type.lineno = child->type.lineno;
new_e->unary.child = child;
new_e->unary.type.node_class = etree_unary;
+ if (child->type.node_class == etree_value
+ && code != ALIGN_K
+ && code != ABSOLUTE
+ && code != NEXT
+ && code != DATA_SEGMENT_END)
+ exp_value_fold (new_e);
return new_e;
}
--
Alan Modra
Australia Development Lab, IBM