This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 ();
 }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]