www.digitalmars.com         C & C++   DMDScript  

D.gnu - 2.064 status, ARM status

reply Johannes Pfau <nospam example.com> writes:
I updated the ARM patches to the latest master version. I have to admit
I was pleasantly surprised that going from 2.063 to 2.064 did not cause
any failing test cases in the test suite or failing unit tests. So ARM
on 2.064 is also good to go now and it's probably a good idea to start
merging the fixes.
(Code is here: https://github.com/jpf91/GDC/commits/arm )

One question related to the 2.064 merge: I see one failing test in the
test suite, file runnable/template9.d. It fails with linker errors.
Is this a known problem or could it be the gcc snapshot version
I'm using (gcc-4.9-20131201)? This happens on x86/64 and ARM.
Dec 09 2013
next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 9 December 2013 14:25, Johannes Pfau <nospam example.com> wrote:

 I updated the ARM patches to the latest master version. I have to admit
 I was pleasantly surprised that going from 2.063 to 2.064 did not cause
 any failing test cases in the test suite or failing unit tests. So ARM
 on 2.064 is also good to go now and it's probably a good idea to start
 merging the fixes.
 (Code is here: https://github.com/jpf91/GDC/commits/arm )

 One question related to the 2.064 merge: I see one failing test in the
 test suite, file runnable/template9.d. It fails with linker errors.
 Is this a known problem or could it be the gcc snapshot version
 I'm using (gcc-4.9-20131201)? This happens on x86/64 and ARM.



I'll take a look.  I might have included it by accident or forgotten a file.
Dec 09 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 9 December 2013 15:17, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 9 December 2013 14:25, Johannes Pfau <nospam example.com> wrote:

 I updated the ARM patches to the latest master version. I have to admit
 I was pleasantly surprised that going from 2.063 to 2.064 did not cause
 any failing test cases in the test suite or failing unit tests. So ARM
 on 2.064 is also good to go now and it's probably a good idea to start
 merging the fixes.
 (Code is here: https://github.com/jpf91/GDC/commits/arm )

 One question related to the 2.064 merge: I see one failing test in the
 test suite, file runnable/template9.d. It fails with linker errors.
 Is this a known problem or could it be the gcc snapshot version
 I'm using (gcc-4.9-20131201)? This happens on x86/64 and ARM.



 I'll take a look.  I might have included it by accident or forgotten a file.


Ah, it was something completely different.  I introduced a bug
refactoring template/decl emission (via cgraph_get_create_node
(decl)->forced_by_abi).

Just going to relax the rules a little bit so that the backend may
remove templates if there are no found calls to them in the cgraph.

Regards
Iain.
Dec 09 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 9 December 2013 16:11, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 9 December 2013 15:17, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 9 December 2013 14:25, Johannes Pfau <nospam example.com> wrote:

 I updated the ARM patches to the latest master version. I have to admit
 I was pleasantly surprised that going from 2.063 to 2.064 did not cause
 any failing test cases in the test suite or failing unit tests. So ARM
 on 2.064 is also good to go now and it's probably a good idea to start
 merging the fixes.
 (Code is here: https://github.com/jpf91/GDC/commits/arm )

 One question related to the 2.064 merge: I see one failing test in the
 test suite, file runnable/template9.d. It fails with linker errors.
 Is this a known problem or could it be the gcc snapshot version
 I'm using (gcc-4.9-20131201)? This happens on x86/64 and ARM.



 I'll take a look.  I might have included it by accident or forgotten a file.


 Ah, it was something completely different.  I introduced a bug
 refactoring template/decl emission (via cgraph_get_create_node
 (decl)->forced_by_abi).

 Just going to relax the rules a little bit so that the backend may
 remove templates if there are no found calls to them in the cgraph.



Nope, that was not a good idea at all...
Dec 09 2013
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/09/2013 06:25 AM, Johannes Pfau wrote:

 I updated the ARM patches to the latest master version. I have to admit
 I was pleasantly surprised that going from 2.063 to 2.064 did not cause
 any failing test cases in the test suite or failing unit tests. So ARM
 on 2.064 is also good to go now and it's probably a good idea to start
 merging the fixes.
 (Code is here: https://github.com/jpf91/GDC/commits/arm )

 One question related to the 2.064 merge: I see one failing test in the
 test suite, file runnable/template9.d. It fails with linker errors.
 Is this a known problem or could it be the gcc snapshot version
 I'm using (gcc-4.9-20131201)? This happens on x86/64 and ARM.


I would love to play with this, but I have had no luck getting it to 
build, either with crosstools or as a native build (I think my board is 
running out of memory, and I know of no way to attach any sort of hard 
disk to it for swap space).

Today I am going to attempt to build it on my dev box with a 
crosstools-built gcc, but I don't expect much.
Dec 14 2013
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 14 December 2013 20:21, Ellery Newcomer <ellery-newcomer utulsa.edu> wrote:

 On 12/09/2013 06:25 AM, Johannes Pfau wrote:

 I updated the ARM patches to the latest master version. I have to admit
 I was pleasantly surprised that going from 2.063 to 2.064 did not cause
 any failing test cases in the test suite or failing unit tests. So ARM
 on 2.064 is also good to go now and it's probably a good idea to start
 merging the fixes.
 (Code is here: https://github.com/jpf91/GDC/commits/arm )

 One question related to the 2.064 merge: I see one failing test in the
 test suite, file runnable/template9.d. It fails with linker errors.
 Is this a known problem or could it be the gcc snapshot version
 I'm using (gcc-4.9-20131201)? This happens on x86/64 and ARM.


 I would love to play with this, but I have had no luck getting it to build,
 either with crosstools or as a native build (I think my board is running out
 of memory, and I know of no way to attach any sort of hard disk to it for
 swap space).


I had a similar problem with my trim slice after upgrading it to
12.04, which has only 1GB memory.  The daft buggers left swap turned
off in the kernel, so I had to recompile linux with it enabled.  Got
myself a serial cable (saved my life!) to get access to the boot
console to first test that the built image work, then voila - I can
now compile gcc. \o/
Dec 14 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 14 Dec 2013 22:16:13 +0000
schrieb Iain Buclaw <ibuclaw gdcproject.org>:


 On 14 December 2013 20:21, Ellery Newcomer
 <ellery-newcomer utulsa.edu> wrote:

 On 12/09/2013 06:25 AM, Johannes Pfau wrote:

 I updated the ARM patches to the latest master version. I have to
 admit I was pleasantly surprised that going from 2.063 to 2.064
 did not cause any failing test cases in the test suite or failing
 unit tests. So ARM on 2.064 is also good to go now and it's
 probably a good idea to start merging the fixes.
 (Code is here: https://github.com/jpf91/GDC/commits/arm )

 One question related to the 2.064 merge: I see one failing test in
 the test suite, file runnable/template9.d. It fails with linker
 errors. Is this a known problem or could it be the gcc snapshot
 version I'm using (gcc-4.9-20131201)? This happens on x86/64 and
 ARM.


 I would love to play with this, but I have had no luck getting it
 to build, either with crosstools or as a native build (I think my
 board is running out of memory, and I know of no way to attach any
 sort of hard disk to it for swap space).


 
 I had a similar problem with my trim slice after upgrading it to
 12.04, which has only 1GB memory.  The daft buggers left swap turned
 off in the kernel, so I had to recompile linux with it enabled.  Got
 myself a serial cable (saved my life!) to get access to the boot
 console to first test that the built image work, then voila - I can
 now compile gcc. \o/


"Only 1GB" ;-)

I've got a first generation model B Raspberry PI, 256 mb ram (shared
with the graphics card). But at least Archlinux works fine on the
Raspberry and swap is supported out of the box :-P
Dec 14 2013
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 14 December 2013 22:24, Johannes Pfau <nospam example.com> wrote:

 Am Sat, 14 Dec 2013 22:16:13 +0000
 schrieb Iain Buclaw <ibuclaw gdcproject.org>:


 On 14 December 2013 20:21, Ellery Newcomer
 <ellery-newcomer utulsa.edu> wrote:

 On 12/09/2013 06:25 AM, Johannes Pfau wrote:

 I updated the ARM patches to the latest master version. I have to
 admit I was pleasantly surprised that going from 2.063 to 2.064
 did not cause any failing test cases in the test suite or failing
 unit tests. So ARM on 2.064 is also good to go now and it's
 probably a good idea to start merging the fixes.
 (Code is here: https://github.com/jpf91/GDC/commits/arm )

 One question related to the 2.064 merge: I see one failing test in
 the test suite, file runnable/template9.d. It fails with linker
 errors. Is this a known problem or could it be the gcc snapshot
 version I'm using (gcc-4.9-20131201)? This happens on x86/64 and
 ARM.


 I would love to play with this, but I have had no luck getting it
 to build, either with crosstools or as a native build (I think my
 board is running out of memory, and I know of no way to attach any
 sort of hard disk to it for swap space).


 I had a similar problem with my trim slice after upgrading it to
 12.04, which has only 1GB memory.  The daft buggers left swap turned
 off in the kernel, so I had to recompile linux with it enabled.  Got
 myself a serial cable (saved my life!) to get access to the boot
 console to first test that the built image work, then voila - I can
 now compile gcc. \o/


 "Only 1GB" ;-)


I like to use all cores on the device when compiling. And the two
*big* compilations in gcc running at the same time was what killed the
device. Saying that it barely compiled the files on their own. ;-)
Dec 16 2013
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 14 Dec 2013 12:21:06 -0800
schrieb Ellery Newcomer <ellery-newcomer utulsa.edu>:


 On 12/09/2013 06:25 AM, Johannes Pfau wrote:

 I updated the ARM patches to the latest master version. I have to
 admit I was pleasantly surprised that going from 2.063 to 2.064 did
 not cause any failing test cases in the test suite or failing unit
 tests. So ARM on 2.064 is also good to go now and it's probably a
 good idea to start merging the fixes.
 (Code is here: https://github.com/jpf91/GDC/commits/arm )

 One question related to the 2.064 merge: I see one failing test in
 the test suite, file runnable/template9.d. It fails with linker
 errors. Is this a known problem or could it be the gcc snapshot
 version I'm using (gcc-4.9-20131201)? This happens on x86/64 and
 ARM.


 
 I would love to play with this, but I have had no luck getting it to 
 build, either with crosstools or as a native build (I think my board
 is running out of memory, and I know of no way to attach any sort of
 hard disk to it for swap space).
 
 Today I am going to attempt to build it on my dev box with a 
 crosstools-built gcc, but I don't expect much.


Hi Ellery,

it seems like crosstool-NG can't compile recent gcc-4.9 snapshots. It's
not a D or crosstool problem actually, GCC-4.9 for some reason can't
bootstrap glibc.

I personally use this branch to test the cross-compiler:
https://github.com/jpf91/GDC/commits/arm-old

It's a quick & dirty backport of the arm branch for gcc-4.8. It should
work as well as the arm branch (it might produce slightly bigger
binaries though, but I couldn't confirm that yet)
Dec 14 2013
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/14/2013 02:21 PM, Johannes Pfau wrote:

 Hi Ellery,

 it seems like crosstool-NG can't compile recent gcc-4.9 snapshots. It's
 not a D or crosstool problem actually, GCC-4.9 for some reason can't
 bootstrap glibc.

 I personally use this branch to test the cross-compiler:
 https://github.com/jpf91/GDC/commits/arm-old

 It's a quick & dirty backport of the arm branch for gcc-4.8. It should
 work as well as the arm branch (it might produce slightly bigger
 binaries though, but I couldn't confirm that yet)


oh, wow. staples. thanks.

heh. 11M hello world. it runs, though.
Dec 14 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 14 Dec 2013 18:04:07 -0800
schrieb Ellery Newcomer <ellery-newcomer utulsa.edu>:


 On 12/14/2013 02:21 PM, Johannes Pfau wrote:

 Hi Ellery,

 it seems like crosstool-NG can't compile recent gcc-4.9 snapshots.
 It's not a D or crosstool problem actually, GCC-4.9 for some reason
 can't bootstrap glibc.

 I personally use this branch to test the cross-compiler:
 https://github.com/jpf91/GDC/commits/arm-old

 It's a quick & dirty backport of the arm branch for gcc-4.8. It
 should work as well as the arm branch (it might produce slightly
 bigger binaries though, but I couldn't confirm that yet)


 
 oh, wow. staples. thanks.
 
 heh. 11M hello world. it runs, though.


That's actually normal, the GCC-4.9 branch also produces a 11MB hello
world. There's a new feature in GCC-4.9 which allows to remove
templates from executables in some cases and as it's not supported in
GCC-4.8 that could cause a difference.

You can use 'strip' (arm-unknown-linux-gnueabi-strip) to get your 11MB
hello world to a reasonable size.
Dec 15 2013
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/15/2013 12:45 AM, Johannes Pfau wrote:

 You can use 'strip' (arm-unknown-linux-gnueabi-strip) to get your 11MB
 hello world to a reasonable size.


right.

stack traces are a little less than helpful:

object.Exception src/robovero.d(82): expected length 1, got '[]'
----------------
0x25f0f ???
         ???:0
0x5f017 ???
         ???:0
0x149e5 ???
         ???:0
0x15183 ???
         ???:0
0x152f9 ???
         ???:0
0x66323 ???
         ???:0
0x6674d ???
         ???:0
0x668d7 ???
         ???:0
0x6674d ???
         ???:0
0x6683f ???
         ???:0
0x14d21 ???
         ???:0
0xb6e10fd9 ???
         ???:0

any idea why that might be?

flags I'm using: -fdebug -g
Dec 15 2013
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 15 December 2013 20:37, Ellery Newcomer <ellery-newcomer utulsa.edu> wrote:

 On 12/15/2013 12:45 AM, Johannes Pfau wrote:

 You can use 'strip' (arm-unknown-linux-gnueabi-strip) to get your 11MB
 hello world to a reasonable size.


 right.

 stack traces are a little less than helpful:

 object.Exception src/robovero.d(82): expected length 1, got '[]'
 ----------------
 0x25f0f ???
         ???:0
 0x5f017 ???
         ???:0
 0x149e5 ???
         ???:0
 0x15183 ???
         ???:0
 0x152f9 ???
         ???:0
 0x66323 ???
         ???:0
 0x6674d ???
         ???:0
 0x668d7 ???
         ???:0
 0x6674d ???
         ???:0
 0x6683f ???
         ???:0
 0x14d21 ???
         ???:0
 0xb6e10fd9 ???
         ???:0

 any idea why that might be?

 flags I'm using: -fdebug -g


No libbacktrace support on ARM?
Dec 15 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 15 Dec 2013 21:42:37 +0000
schrieb Iain Buclaw <ibuclaw gdcproject.org>:


 On 15 December 2013 20:37, Ellery Newcomer
 <ellery-newcomer utulsa.edu> wrote:

 On 12/15/2013 12:45 AM, Johannes Pfau wrote:

 You can use 'strip' (arm-unknown-linux-gnueabi-strip) to get your
 11MB hello world to a reasonable size.


 right.

 stack traces are a little less than helpful:

 object.Exception src/robovero.d(82): expected length 1, got '[]'
 ----------------
 0x25f0f ???
         ???:0
 0x5f017 ???
         ???:0
 0x149e5 ???
         ???:0
 0x15183 ???
         ???:0
 0x152f9 ???
         ???:0
 0x66323 ???
         ???:0
 0x6674d ???
         ???:0
 0x668d7 ???
         ???:0
 0x6674d ???
         ???:0
 0x6683f ???
         ???:0
 0x14d21 ???
         ???:0
 0xb6e10fd9 ???
         ???:0

 any idea why that might be?

 flags I'm using: -fdebug -g


 
 No libbacktrace support on ARM?


Libbacktrace is actually supported on ARM and stacktraces works just
fine, even with cross-compilers. There must be a problem with your gdc
build, Ellery. Can you check the contents of 
include/d/4.8.0/gcc/libbacktrace.di
especially the BACKTRACE_SUPPORTED enum?
Dec 21 2013
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/21/2013 04:04 PM, Johannes Pfau wrote:

 flags I'm using: -fdebug -g


 No libbacktrace support on ARM?


 Libbacktrace is actually supported on ARM and stacktraces works just
 fine, even with cross-compilers. There must be a problem with your gdc
 build, Ellery. Can you check the contents of
 include/d/4.8.0/gcc/libbacktrace.di
 especially the BACKTRACE_SUPPORTED enum?


Looks like include/d didn't make it into the final deployment. or etc.
Dec 29 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 29 Dec 2013 17:15:47 -0800
schrieb Ellery Newcomer <ellery-newcomer utulsa.edu>:


 On 12/21/2013 04:04 PM, Johannes Pfau wrote:

 flags I'm using: -fdebug -g


 No libbacktrace support on ARM?


 Libbacktrace is actually supported on ARM and stacktraces works just
 fine, even with cross-compilers. There must be a problem with your
 gdc build, Ellery. Can you check the contents of
 include/d/4.8.0/gcc/libbacktrace.di
 especially the BACKTRACE_SUPPORTED enum?


 
 Looks like include/d didn't make it into the final deployment. or etc.


Sorry, I forgot that the paths are different for cross-compilers. It
should
be /arm-unknown-linux-gnueabihf/lib/gcc/arm-unknown-linux-gnueabihf/4.8.2/include/d/gcc/libbacktrace.di

Just to be sure: You also don't get a backtrace with symbols even if
you don't use 'strip'? I use a hg version of crosstool-NG and maybe they
changed something since the last release but I didn't have to use any
special options.
Dec 30 2013
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/30/2013 12:22 PM, Johannes Pfau wrote:

 Sorry, I forgot that the paths are different for cross-compilers. It
 should
 be /arm-unknown-linux-gnueabihf/lib/gcc/arm-unknown-linux-gnueabihf/4.8.2/include/d/gcc/libbacktrace.di

 Just to be sure: You also don't get a backtrace with symbols even if
 you don't use 'strip'? I use a hg version of crosstool-NG and maybe they
 changed something since the last release but I didn't have to use any
 special options.


Well, that'll teach me to not use find. from libbacktrace.di:

enum HAVE_DLADDR = false;
...
enum BACKTRACE_SUPPORTED = true;
enum BACKTRACE_USES_MALLOC = false;
enum BACKTRACE_SUPPORTS_THREADS = true;



I do get a [partial] backtrace with non stripped executables:

----------------
0xd027 _Dmain
	???:0
0xfe07 void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll().void __lambda1()
	/opt/cortex-a8/arm-eabi/.build/src/gcc-4.8.1/libphobos/libdruntime/rt/dmain2.d:412
0x10231 void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate())
	/opt/cortex-a8/arm-eabi/.build/src/gcc-4.8.1/libphobos/libdruntime/rt/dmain2.d:387
0x103bb void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll()
	/opt/cortex-a8/arm-eabi/.build/src/gcc-4.8.1/libphobos/libdruntime/rt/dmain2.d:412
0x10231 void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate())
	/opt/cortex-a8/arm-eabi/.build/src/gcc-4.8.1/libphobos/libdruntime/rt/dmain2.d:387
0x10323 _d_run_main
	/opt/cortex-a8/arm-eabi/.build/src/gcc-4.8.1/libphobos/libdruntime/rt/dmain2.d:420
0xcfcd main
	???:0
0xb6db9fd9 ???
	???:0

and it references the location I built the cross compiler, yay! (?)
Dec 30 2013