[ECOS] One question..

[anton yakovlev]

Gary Thomas wrote:

>On Sat, 2004-06-26 at 06:26, anton yakovlev wrote:
>  
>
>>Gary Thomas wrote:
>>
>>    
>>
>>>On Sat, 2004-06-26 at 02:59, anton yakovlev wrote:
>>>      
>>>
>>>.. skipped ..
>>>      
>>>
>>Hm.. I did not think about this.. I use GNU ld with "-L <smth> 
>>-Wl,--gc-sections -nostartfiles -Ttarget.ld -nostdlib" flags.. Simple 
>>"hello, world" and some more complex programms work's properly.. How to 
>>check, which way the program was linked?..
>>    
>>
>
>The command "XXX-objdump -h file.elf" will show how the program was
>linked.
>  
>
(19:39:25 snoopy@starlake:project)$ v850-elf-objdump -h binary/tracker.elf

binary/tracker.elf:     file format elf32-v850

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000cf7e  00205000  00205000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .fini         00000000  00211f80  00211f80  0001780c  2**0
                  CONTENTS
  2 .rodata       00005faa  00211f80  00211f80  0000df80  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .rodata1      00000000  00217f2c  00217f2c  0001780c  2**0
                  CONTENTS
  4 .fixup        00000000  00217f2c  00217f2c  0001780c  2**0
                  CONTENTS
  5 .gcc_except_table 00000000  00217f2c  00217f2c  0001780c  2**0
                  CONTENTS
  6 .data         000038e0  00217f2c  00217f2c  00013f2c  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  7 .bss          00004604  0021b80c  0021b80c  0001780c  2**2
                  ALLOC
  8 .v850_ram     00000000  ffffe500  ffffe500  0001780c  2**0
                  CONTENTS
  9 .stab         00041a9c  00000000  00000000  0001780c  2**2
                  CONTENTS, READONLY, DEBUGGING
 10 .stabstr      00067796  00000000  00000000  000592a8  2**0
                  CONTENTS, READONLY, DEBUGGING

It seems, that program linked correctly..

>>PS: When I turn on full kernel debug, that my above programm work's 
>>fine.. but when I try to execute more complex multithreaded program, 
>>this programm failed while system initialization with "ASSERT FAIL: 
>>mutex.cxx cyg_bool Cyg_Mutex::lock()".. :(
>>    
>>
>
>This would be a separate problem.  Have you run the standard tests to 
>see how they perform on your platform?
>  
>
There are all kernel tests, that I have:

bin_sem0: are not compiled
bin_sem1: OK
bin_sem2: are not compiled
bin_sem3: OK
clock0: are not compiled
clock1: OK
clockcnv: OK
clocktruth: are not compiled
cnt_sem0: are not compiled
cnt_sem1: OK
dhrystone: NOTAPPLICABLE
except1: FAIL
flag0: are not compiled
flag1: OK
fptest: does not work, because problems with threads
intr0: OK
kalarm0: OK
kcache1: NOTAPPLICABLE
kcache2: NOTAPPLICABLE
kclock0: OK
kclock1: OK
kexcept1: FAIL
kflag0: OK
kflag1: OK
kill: OK
kintr0: OK
klock: OK
kmbox1: FAIL
kmutex0: OK
kmutex1: OK
kmutex3: OK
kmutex4: OK
kphilo: OK
ksched1: OK
ksem0: OK
ksem1: OK
kthread0: OK
kthread1: OK
mbox1: OK
mqueue1: are not compiled
mutex0: are not compiled
mutex1: OK
mutex2: OK
mutex3: OK
philo: are not compiled
release: OK
sched1: OK
smp: NOTAPPLICABLE
stress_threads: FAIL
sync2: OK
sync3: OK
tcdiag: are not compiled
thread0: are not compiled
thread1: OK
thread2: OK
thread_gdb: OK
timeslice: OK
tm_basic: are not compiled

Tests, that "are not compiled", failed while compilation with "undefined 
reference to `___gxx_personality_sj0'" error..


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss