This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Relative expressions and ASSERT
On Thu, Dec 16, 2010 at 3:14 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Dec 16, 2010 at 2:58 PM, Alan Modra <amodra@gmail.com> wrote:
>> On Thu, Dec 16, 2010 at 08:50:56AM -0800, H.J. Lu wrote:
>>> On Thu, Dec 16, 2010 at 7:48 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
>>> > On Thu, Dec 16, 2010 at 09:32:43PM +1030, Alan Modra wrote:
>>> >> How to people feel about this for 2.21.1?
>>> >
>>> > IMO, this is a more logical behavior. And there's going to be some
>>> > incompatibilities in the linker script language whether we do it or
>>> > not.
>>> >
>>>
>>> I am against regressions in known linker scripts, including those
>>> in linker testsuites. We should take a closer look at what we did
>>> and fix it properly.
>>
>> You would rather stay with expression evaluation that we couldn't even
>> describe?
>
> Well, I consider linker tests within binutils testsuite are valid usages and
> we should do our best not to break them.
>
>> I made a deliberate change, trying to minimize breakage but knowing
>> that we surely would break some scripts that use more complex
>> expressions. ?I also knew that symbol assignment outside of an output
>> section statement would result in absolute symbols, but hoped this
>> would not affect too many people. ?It seems it does, so I offered this
>> further patch that cures the symbol assignment problem, *and*
>> simplifies the linker expression evaluation rules. ?The tradeoff being
>> that this may break more complex expressions.
>>
>> Can you verify that this fixes the x86_64 kernel build breakage?
>>
>
> Your patch doesn't work. I got
>
> ./ld: kernel image bigger than KERNEL_IMAGE_SIZE
>
> due to arch/x86/kernel/vmlinux.lds:
>
> ----
> /*
> ?* Build-time check on the image size:
> ?*/
> . = ASSERT((_end - _text <= (512 * 1024 * 1024)),
> ? ?"kernel image bigger than KERNEL_IMAGE_SIZE");
> . = ASSERT((irq_stack_union == 0),
> ? ? ? ? ? "irq_stack_union is not at start of per-cpu area");
> . = ASSERT(kexec_control_code_size <= 2048,
> ? ? ? ? ? "kexec control code size is too big");
>
This hack may work.
--
H.J.
---
diff --git a/ld/ldexp.c b/ld/ldexp.c
index de7f9f2..5d27287 100644
--- a/ld/ldexp.c
+++ b/ld/ldexp.c
@@ -691,12 +691,15 @@ fold_name (etree_type *tree)
static void
exp_fold_tree_1 (etree_type *tree)
{
+ asection *defined;
+
if (tree == NULL)
{
memset (&expld.result, 0, sizeof (expld.result));
return;
}
+ defined = NULL;
switch (tree->type.node_class)
{
case etree_value:
@@ -851,6 +854,17 @@ exp_fold_tree_1 (etree_type *tree)
case etree_name:
fold_name (tree);
+ if (link_info.hash)
+ {
+ struct bfd_link_hash_entry *h;
+
+ h = bfd_link_hash_lookup (link_info.hash, tree->name.name,
+ FALSE, FALSE, TRUE);
+ if (h
+ && (h->type == bfd_link_hash_defined
+ || h->type == bfd_link_hash_defweak))
+ defined = h->u.def.section;
+ }
break;
default:
@@ -862,7 +876,10 @@ exp_fold_tree_1 (etree_type *tree)
/* Any value not inside an output section statement is an
absolute value. */
if (expld.result.valid_p
- && expld.section == bfd_abs_section_ptr)
+ && expld.section == bfd_abs_section_ptr
+ && (tree->type.node_class != etree_name
+ || !defined
+ || defined == bfd_abs_section_ptr))
make_abs ();
}