Re: Relative expressions and ASSERT

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

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");

---

-- 
H.J.