December 15, 2013 Re: 2.064 status, ARM status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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 |
December 15, 2013 Re: 2.064 status, ARM status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ellery Newcomer | 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?
|
December 16, 2013 Re: 2.064 status, ARM status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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. ;-)
|
December 22, 2013 Re: 2.064 status, ARM status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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? |
December 30, 2013 Re: 2.064 status, ARM status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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.
|
December 30, 2013 Re: 2.064 status, ARM status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ellery Newcomer | 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. |
December 30, 2013 Re: 2.064 status, ARM status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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! (?) |
Copyright © 1999-2021 by the D Language Foundation