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

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?

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

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?

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.

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.

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! (?)