Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-18 Thread Phil Blundell 
On Tue, 2015-11-17 at 17:09 +, Phil Blundell wrote:
> On Tue, 2015-11-17 at 16:44 +, Burton, Ross wrote:
> > 
> > 
> > On 17 November 2015 at 15:16, Phil Blundell  wrote:
> > 
> > > Does the resulting directfb-csource binary actually work with that
> > > change?  My recollection is that ld.bfd will just silently permit
> > > relocs that gold (correctly) refuses to allow.
> > > 
> > > 
> > 
> > 
> > Personally I don't use DirectFB (and am constantly surprised it's
> > still a thing) so at this point I'm not going to merge either of
> > these patches until someone can confirm that their fix *works on
> > hardware* instead of just fixing the build.
> 
> 
> I think that's a reasonable position.  In any case, the underlying
> issue is a compiler bug and ought really to be fixed there rather than
> patching directfb or any other package that just happens to fall over
> it.

I had another look at this and my previous recollection was not quite
right.  What's happening here is that we have:

movwr1, #:lower16:longjmp
mov r2, #392
movtr1, #:upper16:longjmp
bl  png_set_longjmp_fn

which is not an unreasonable thing for the compiler to generate in the
circumstances and results in the assembler producing:

0798  722b R_ARM_MOVW_ABS_NC    longjmp
07a0  722c R_ARM_MOVT_ABS   longjmp

   114:  0 NOTYPE  GLOBAL DEFAULT  UND longjmp

which is also fine.  However gold is getting a bit mixed up and seems to
be forgetting to generate a plt entry for longjmp.  Instead it tries to
produce:

a124  132b R_ARM_MOVW_ABS_NC    longjmp
a12c  132c R_ARM_MOVT_ABS   longjmp

19:  0 FUNCGLOBAL DEFAULT  UND longjmp@GLIBC_2.4 (4)
   104:  0 FUNCGLOBAL DEFAULT  UND longjmp

which is bogus.

So, contrary to what I said before, I don't think gcc is doing anything
wrong and it seems fairly clear that the bug is in gold.  That being the
case, I think switching to ld.bfd is a reasonable workaround.  Adding
-fPIC also works around the problem in a different way (it replaces the
MOVx_ABS relocs with a load from the constant pool and a corresponding
GLOB_DAT reloc) but this will produce worse code.  So I would be
inclined to merge Andre's patch.  If someone wanted to distil a testcase
from this and file a bug against gold upstream then that would be even
better.

p.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-17 Thread Phil Blundell 
On Mon, 2015-11-16 at 21:56 -0800, Andre McCurdy wrote:
> 
+# Workaround for linking issues seen with armv7a + gold
> +LDFLAGS_append_armv7a = "${@base_contains('DISTRO_FEATURES', 'ld-is
> -gold', ' -fuse-ld=bfd ', '', d)}"
> 

Does the resulting directfb-csource binary actually work with that
change?  My recollection is that ld.bfd will just silently permit
relocs that gold (correctly) refuses to allow.

p.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-17 Thread Burton, Ross 
On 17 November 2015 at 05:56, Andre McCurdy  wrote:

>  |
> .../build/tmp/sysroots/x86_64-linux/usr/bin/arm-rdk-linux-gnueabi/../../libexec/arm-rdk-linux-gnueabi/gcc/arm-rdk-linux-gnueabi/5.2.0/ld:
> error: directfb-csource.o: requires unsupported dynamic reloc
> R_ARM_MOVW_ABS_NC; recompile with -fPIC
>

Martin just sent a patch to pass -fPIC, presumably that is preferable to
changing the linker?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-17 Thread Phil Blundell 
On Tue, 2015-11-17 at 16:44 +, Burton, Ross wrote:
> 
> On 17 November 2015 at 15:16, Phil Blundell  wrote:
> > Does the resulting directfb-csource binary actually work with that
> > change?  My recollection is that ld.bfd will just silently permit
> > relocs that gold (correctly) refuses to allow.
> > 
> Personally I don't use DirectFB (and am constantly surprised it's
> still a thing) so at this point I'm not going to merge either of
> these patches until someone can confirm that their fix *works on
> hardware* instead of just fixing the build.
I think that's a reasonable position.  In any case, the underlying
issue is a compiler bug and ought really to be fixed there rather than
patching directfb or any other package that just happens to fall over
it.
p.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-17 Thread Burton, Ross 
On 17 November 2015 at 15:16, Phil Blundell  wrote:

> Does the resulting directfb-csource binary actually work with that
> change?  My recollection is that ld.bfd will just silently permit
> relocs that gold (correctly) refuses to allow.
>

Personally I don't use DirectFB (and am constantly surprised it's still a
thing) so at this point I'm not going to merge either of these patches
until someone can confirm that their fix *works on hardware* instead of
just fixing the build.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-17 Thread Andre McCurdy 
On Tue, Nov 17, 2015 at 9:09 AM, Phil Blundell  wrote:
> On Tue, 2015-11-17 at 16:44 +, Burton, Ross wrote:
>
> On 17 November 2015 at 15:16, Phil Blundell  wrote:
>
> Does the resulting directfb-csource binary actually work with that
> change?  My recollection is that ld.bfd will just silently permit
> relocs that gold (correctly) refuses to allow.
>
>
> Personally I don't use DirectFB (and am constantly surprised it's still a
> thing) so at this point I'm not going to merge either of these patches until
> someone can confirm that their fix *works on hardware* instead of just
> fixing the build.
>
>
> I think that's a reasonable position.  In any case, the underlying issue is
> a compiler bug and ought really to be fixed there rather than patching
> directfb or any other package that just happens to fall over it.
>

The directfb-csource binary linked with the bfd linker segfaults on
startup, so it does indeed look like a compiler problem.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-17 Thread Andre McCurdy 
On Tue, Nov 17, 2015 at 11:33 AM, Khem Raj  wrote:
> On Tue, Nov 17, 2015 at 7:16 AM, Phil Blundell  wrote:
>> On Mon, 2015-11-16 at 21:56 -0800, Andre McCurdy wrote:
>>>
>> +# Workaround for linking issues seen with armv7a + gold
>>> +LDFLAGS_append_armv7a = "${@base_contains('DISTRO_FEATURES', 'ld-is
>>> -gold', ' -fuse-ld=bfd ', '', d)}"
>>>
>>
>> Does the resulting directfb-csource binary actually work with that
>> change?  My recollection is that ld.bfd will just silently permit
>> relocs that gold (correctly) refuses to allow.
>
> thats right. real problem here is that there is a static library
> generating with out pic options and being linked into
> shared object. gold is flagging it since it will fail at runtime.
> Please pass --enable-shared to configure that should help
> if that does not then pass -fPIC in CFLAGS

Note that directfb-csource is an application, not a shared library.

First directfb-csource.c is compiled to directfb-csource.o and then
directfb-csource.o is linked with -lpng16 -ldl -lrt -lpthread to
create the directfb-csource application. I don't see an obvious reason
why -fPIC should be needed when directfb-csource.c is compiled?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-17 Thread Andre McCurdy 
On Tue, Nov 17, 2015 at 11:34 AM, Andre McCurdy  wrote:
> On Tue, Nov 17, 2015 at 11:16 AM, Andre McCurdy  wrote:
>> On Tue, Nov 17, 2015 at 9:09 AM, Phil Blundell  wrote:
>>> On Tue, 2015-11-17 at 16:44 +, Burton, Ross wrote:
>>>
>>> On 17 November 2015 at 15:16, Phil Blundell  wrote:
>>>
>>> Does the resulting directfb-csource binary actually work with that
>>> change?  My recollection is that ld.bfd will just silently permit
>>> relocs that gold (correctly) refuses to allow.
>>>
>>> Personally I don't use DirectFB (and am constantly surprised it's still a
>>> thing) so at this point I'm not going to merge either of these patches until
>>> someone can confirm that their fix *works on hardware* instead of just
>>> fixing the build.
>>>
>>> I think that's a reasonable position.  In any case, the underlying issue is
>>> a compiler bug and ought really to be fixed there rather than patching
>>> directfb or any other package that just happens to fall over it.
>>
>> The directfb-csource binary linked with the bfd linker segfaults on
>> startup, so it does indeed look like a compiler problem.
>
> Hmmm... maybe I spoke too soon. lsmod is also segfaulting on startup
> so there's something else going wrong with this build.
>
> If I copy the same directfb-csource binary into a rootfs built with
> security_flags.inc enabled then it runs OK...

OK, so the segfaults were due to building Jethro with prelink enabled :-(

With prelink disabled, directfb-csource linked with the bfd linker
runs fine on real HW:

root@eos:~# cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 3 (v7l)
Features: swp half thumb fastmult vfp edsp neon vfpv3 tls
vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x42
CPU architecture: 7
CPU variant : 0x0
CPU part: 0x00f
CPU revision: 3

processor   : 1
model name  : ARMv7 Processor rev 3 (v7l)
Features: swp half thumb fastmult vfp edsp neon vfpv3 tls
vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x42
CPU architecture: 7
CPU variant : 0x0
CPU part: 0x00f
CPU revision: 3

Hardware: Broadcom STB (Flattened Device Tree)
Revision: 
Serial  : 
root@eos:~#
root@eos:~# directfb-csource
directfb-csource version 1.7.7

Usage: directfb-csource [options] 
   --name=  specifies variable name
   --format=specifies surface format
   --rgbformat= specifies format for non-alpha images
   --multi multiple images
   --raw   dump a single file directly to header
   --dither-rgb16  dither images rendered to RGB16 surfaces
   --help  show this help message
   --version   print version information

See the directfb-csource(1) man-page for more information.

root@eos:~#
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-17 Thread Andre McCurdy 
On Tue, Nov 17, 2015 at 11:16 AM, Andre McCurdy  wrote:
> On Tue, Nov 17, 2015 at 9:09 AM, Phil Blundell  wrote:
>> On Tue, 2015-11-17 at 16:44 +, Burton, Ross wrote:
>>
>> On 17 November 2015 at 15:16, Phil Blundell  wrote:
>>
>> Does the resulting directfb-csource binary actually work with that
>> change?  My recollection is that ld.bfd will just silently permit
>> relocs that gold (correctly) refuses to allow.
>>
>>
>> Personally I don't use DirectFB (and am constantly surprised it's still a
>> thing) so at this point I'm not going to merge either of these patches until
>> someone can confirm that their fix *works on hardware* instead of just
>> fixing the build.
>>
>>
>> I think that's a reasonable position.  In any case, the underlying issue is
>> a compiler bug and ought really to be fixed there rather than patching
>> directfb or any other package that just happens to fall over it.
>>
>
> The directfb-csource binary linked with the bfd linker segfaults on
> startup, so it does indeed look like a compiler problem.

Hmmm... maybe I spoke too soon. lsmod is also segfaulting on startup
so there's something else going wrong with this build.

If I copy the same directfb-csource binary into a rootfs built with
security_flags.inc enabled then it runs OK...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb.inc: force bfd linker for armv7a

2015-11-17 Thread Khem Raj 
On Tue, Nov 17, 2015 at 7:16 AM, Phil Blundell  wrote:
> On Mon, 2015-11-16 at 21:56 -0800, Andre McCurdy wrote:
>>
> +# Workaround for linking issues seen with armv7a + gold
>> +LDFLAGS_append_armv7a = "${@base_contains('DISTRO_FEATURES', 'ld-is
>> -gold', ' -fuse-ld=bfd ', '', d)}"
>>
>
> Does the resulting directfb-csource binary actually work with that
> change?  My recollection is that ld.bfd will just silently permit
> relocs that gold (correctly) refuses to allow.

thats right. real problem here is that there is a static library
generating with out pic options and being linked into
shared object. gold is flagging it since it will fail at runtime.
Please pass --enable-shared to configure that should help
if that does not then pass -fPIC in CFLAGS
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core