[PATCH 2/3] arm: Remove optpld macro

[Pat Pannuto]

[re-send b/c list rejected large attachment; compressed and trying again]

>
>> My understanding is that every "top-level" (global) invocation of the
>> asm()
>> directive is converted into its own object and evaluation independently by
>> LTO.
>
>
> I don't think that can be the case here.  The asm() block in question is an
> (assembler) _macro_, not some piece of code that the linker would ever even
> get to see.
>
> If this construct were to fail, it would have to fail in the compiler or
> assembler.  Once past those, there's nothing left of it for the linker to do
> anything with.  The linker can't fail on something it never sees.

I'm the first to admit that I don't know exactly how LTO works, but my
understanding is that the gist of it is "compiling" in LTO-land doesn't do
very much, just saves the AST in the object to be compiled later, what's
traditionally compilation and linking are both done by the linker.

In this case, the "linker" definitely sees assembly, here's the error:

    arm-none-eabi-gcc -Wl,-pie -Wl,--gc-sections -Wl,--emit-relocs
--entry=_start -std=gnu11 -I../../libtock -DSTACK_SIZE=2048
-I../../libtock -g -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Os -flto
-ffat-lto-objects -fdata-sections -ffunction-sections -Wall -Wextra -g
-fPIC -msingle-pic-base -mpic-register=r9
-mno-pic-data-is-text-relative -T ../../linker.ld -nostdlib
-Wl,--start-group build/cortex-m4/main.o ....snip list of objects....
-Wl,--end-group -Wl,-Map=build/cortex-m4/app.Map -o
build/cortex-m4/app.elf
    <snip irrelevant warnings>
    /var/folders/_t/61hmf1293xq508hf1ksgyp900000gn/T//ccyLTEeK.s:
Assembler messages:
    /var/folders/_t/61hmf1293xq508hf1ksgyp900000gn/T//ccyLTEeK.s:821:
Error: bad instruction `return'
    lto-wrapper: fatal error: arm-none-eabi-gcc returned 1 exit status
    compilation terminated.
    /usr/local/Cellar/arm-none-eabi-gcc/6-2016-q4-update/bin/../lib/gcc/arm-none-eabi/6.2.1/../../../../arm-none-eabi/bin/ld:
error: lto-wrapper failed

I've also attached that intermediate .s file that compilation process generated,
the un-macro'd RETURN is on line 821.

>
>> The asm() block that was #include'd isn't referenced by anything so it's
>> dropped (which makes sense for what LTO is trying to do).
>
>
> It wouldn't even matter whether it's dropped or not.  By the time LTO begins
> its work, assembler macros have been applied and ceased to exist, anyway.
>
>> Sorry, that's a bit of sloppy language on my part. newlib with LTO
>> compiles
>> just fine without this patch, but during the final link of the end
>> application,
>> this becomes an issue.
>
>
> I may have overlooked it, but I don't think you've ever actually shown what
> that "issue" actually was.  So what was the actual error you observed, in
> what kind of usage?  Is there any chance for a small, self-contained test
> case that reproduces it?
>

To replicate yourself:

   - git clone https://github.com/helena-project/tock/
   - git checkout bfa44b2ed
   - cd userland/examples/rot13_client
   - make

I can try to pare down to a smaller example if needed, but it's hard to predict
when this macro thing will be an issue, seems to depend on what LTO chooses
to do

On Sat, Jan 14, 2017 at 7:10 PM, Hans-Bernhard Bröker
<HBBroeker@t-online.de> wrote:
> Am 14.01.2017 um 06:19 schrieb Pat Pannuto:
>
>>> The macro definition is not an assembly block as such, but rather just
>>> that: a macro definition which is supposed to be evaluated at compile
>>> (or assemble) time.
>
>
> Not just supposed to.  That's the only way it can be used.
>
>> My understanding is that every "top-level" (global) invocation of the
>> asm()
>> directive is converted into its own object and evaluation independently by
>> LTO.
>
>
> I don't think that can be the case here.  The asm() block in question is an
> (assembler) _macro_, not some piece of code that the linker would ever even
> get to see.
>
> If this construct were to fail, it would have to fail in the compiler or
> assembler.  Once past those, there's nothing left of it for the linker to do
> anything with.  The linker can't fail on something it never sees.
>
>> The asm() block that was #include'd isn't referenced by anything so it's
>> dropped (which makes sense for what LTO is trying to do).
>
>
> It wouldn't even matter whether it's dropped or not.  By the time LTO begins
> its work, assembler macros have been applied and ceased to exist, anyway.
>
>> Sorry, that's a bit of sloppy language on my part. newlib with LTO
>> compiles
>> just fine without this patch, but during the final link of the end
>> application,
>> this becomes an issue.
>
>
> I may have overlooked it, but I don't think you've ever actually shown what
> that "issue" actually was.  So what was the actual error you observed, in
> what kind of usage?  Is there any chance for a small, self-contained test
> case that reproduces it?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ccyLTEeK.s.bz2
Type: application/x-bzip2
Size: 13193 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20170115/46d55e37/attachment.bz2>