6

I have a "Seagate Central" NAS with an embedded linux on it

$ cat /etc/*release
MontaVista Linux 6, (.dev-snapshot-20130726)

When I try to run my own application on this NAS, it will be "Killed" without any notifications on dmesg or /var/log/messages

$ cat /proc/cpuinfo
Processor       : ARMv6-compatible processor rev 4 (v6l)
BogoMIPS        : 279.34
Features        : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb02
CPU revision    : 4

Hardware        : Cavium Networks CNS3420 Validation Board
Revision        : 0000
Serial          : 0000000000000000

My toolchain is

Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/arm-none-linux-gnueabi

and my compile switches are

-march=armv6k -mcpu=mpcore -mfloat-abi=softfp -mfpu=vfp

How can I find out which process is killing my application, or what setting I have to change?

PS: I have created a simple HelloWorld application which is also not working !

$ ldd Hello
$       not a dynamic executable


readelf -a Hello
=> http://pastebin.com/kT9FvkjE

readelf -a zip
=> http://pastebin.com/3V6kqA9b

UPDATE 1

I have comiled a new binary with hard float

 Readelf output
 http://pastebin.com/a87bKksY

But no success ;(

I guess it is really a "lock" topic, which is blocking my application to execute. How can I find out what application kills mine ? Or how can I disable such kind of function ?

element
  • 71
  • 6

4 Answers4

3

Use these compiler switches:

-march=armv6k -Wl,-z,max-page-size=0x10000,-z,common-page-size=0x10000,-Ttext-segment=0x10000

See also this link regarding the toolchain.

You can run readelf -a against one of the built-in binaries (e.g. /usr/bin/nano) to see the proper text-segment offset in the section headers and page size / alignment in the program headers. The above compiler flags make self-compiled programs match the structure of built in binaries, and have been tested to work. It seems the Seagate Central NAS uses a page size / offset of 0x10000 while the default for ARM gcc is 0x8000.

Edit: I see you ran readelf already. Your pastebin shows

HelloWorld:[ 1] .interp           PROGBITS        00008134 000134 000013 00   A  0   0  1
       zip:[ 1] .interp           PROGBITS        00010134 000134 000013 00   A  0   0  1

The value 10134-134=10000 (hex) yields the correct text-segment linker option. Further down (LOAD...) are the alignment specifiers, which are 0x8000 for your HelloWorld, but 0x10000 for the zip built-in. In my experience, soft-float has not caused problems.

norstadt
  • 31
  • 3
  • 1
    Please add some explanation to your post. It may very well be correct, but an answer with no explanation doesn't really help the asker that much or help any future users who may come across this issue. Adding even a simple explanation allows someone do get an idea of **why** this works and helps them start their own research. – Avery Jul 06 '14 at 16:10
1

Do you see any output at all?

Is your application dynamically linked?

If so, run the dynamic linker with the verbose option (you'll have to figure out the name of the dynamic linker on your platform, for Arch linux, it is ldd):

ldd --verbose 'your_program_name'

That will tell you if you're missing any dependencies (shared libs etc)

Run readelf -a 'your_program_name'

Make sure the file mentioned in Requesting program interpreter: /lib/ld-linux.so.2 exists. In this case, that filename is /lib/ld-linux.so.2

If this fails to help you figure out the problem, post the complete output of ldd --verbose 'your_program_name' and readelf -a 'your_program_name' in your question.

Another issue may be that the NAS software just kills foreign programs. I'm not sure why it would, but we're talking about a big corporation here (Seagate) and they have odd ideas of how the world works at times...

Edit, after looking at the pastebin of readelf:

From what I see, your Hello executable differs in 2 ways from the zip executable:

  • It is not dynamically linked, so that throws out a whole load of problems to look for.

  • There's a difference in how the 2 programs are built. zip does not use softfloats and Hello does. I suspect the soft-float dependency is due to one or both of these compiler switches: -mfloat-abi=softfp -mfpu=vfp

Hello Flags: 0x5000202, has entry point, Version5 EABI, soft-float ABI

zip Flags: 0x5000002, has entry point, Version5 EABI

I'd start with either:

  • Removing the soft-float option from the Hello build or:
  • make sure the soft-float emulation libraries are on the machine. I don't know what libs this would depend on, but I do remember MontaVista supplying them the last time I touched their software. It's been 8+ years since I touched MontaVista so it's clouded in a bit of old-memory fog.
Community
  • 1
  • 1
JimR
  • 15,513
  • 2
  • 20
  • 26
1

This is an old thread, but I just wanted to add that I succeeded in compiling a "hello world" for this old NAS today.

Running ld-linux.so.3 <app> told me that

ELF load command alignment not page-aligned

Googling this, I found this: https://github.com/JuliaLang/julia/issues/33293, which pointed me to linker-options:

-Wl,-z,max-page-size=0x10000

Compiling with these options yielded en ELF that actually did work!

buddemat
  • 4,552
  • 14
  • 29
  • 49
Oklo
  • 11
  • 2
0

Are you sure your compilation options are correct ? Try the following :

  • strace your application (if strace is present on the NAS)
  • downloas one of the NAS binary and run arm-none-linux-gnueabi-readelf -a on it, do the same on your helloworld program and see if the abi tag differ.

It looks like an illegal instruction issue, a floating point issue or an incompatible libc issue.

Edit : according to readelf output, nas program are compiled without soft float, you should try that.

shodanex
  • 14,975
  • 11
  • 57
  • 91
  • strace is not available on NAS ... but I have copied my application and "zip" which is installed on NAS and created readelfs HelloWorld: http://pastebin.com/kT9FvkjE zip : http://pastebin.com/3V6kqA9b – element Oct 29 '13 at 09:07
  • @element : try without soft float – shodanex Oct 29 '13 at 10:42