Re: Relative expressions and ASSERT

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Dec 16, 2010 at 3:17 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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:
>>

I am testing this patch.


H.J.
--
diff --git a/ld/ldexp.c b/ld/ldexp.c
index de7f9f2..c8fa331 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)
 {
+  bfd_boolean absolute;
+
   if (tree == NULL)
     {
       memset (&expld.result, 0, sizeof (expld.result));
       return;
     }

+  absolute = TRUE;
   switch (tree->type.node_class)
     {
     case etree_value:
@@ -851,6 +854,21 @@ exp_fold_tree_1 (etree_type *tree)

     case etree_name:
       fold_name (tree);
+      if (tree->name.name
+	  && tree->name.name[0] != '.'
+	  && tree->name.name[1] != '\0'
+	  && link_info.hash)
+	{
+	  struct bfd_link_hash_entry *h;
+
+	  /* Only make absolute symbol value absolute.  */
+	  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))
+	    absolute = (h->u.def.section == bfd_abs_section_ptr);
+	}
       break;

     default:
@@ -861,7 +879,8 @@ exp_fold_tree_1 (etree_type *tree)

   /* Any value not inside an output section statement is an
      absolute value.  */
-  if (expld.result.valid_p
+  if (absolute
+      && expld.result.valid_p
       && expld.section == bfd_abs_section_ptr)
     make_abs ();
 }