Eclipse Community Forums: C / C++ IDE (CDT) » arm remote debug loses executable flag

Home » Language IDEs » C / C++ IDE (CDT) » arm remote debug loses executable flag(binary is transferred but is not executable; debian wheezy, eclipse kepler, raspberry pi target)

Show: Today's Messages :: Show Polls :: Message Navigator

arm remote debug loses executable flag [message #1292259]

Fri, 11 April 2014 17:14

Timothy Golden

Messages: 6
Registered: April 2014

Junior Member

I am getting eclipse going to debug remotely on raspberry pi and arm in general.
I've tried various configurations, but all seem to have this problem.
The executable does transfer to the pi target, but it has lost it's executable flag.
when I manually chmod+x the binary does run, and it is just the default hello application. The error in the console reads:
*****console output******
Process /home/tim/spi/gdbremote/exp1 created; pid = 32066
/home/tim/pi>
Cannot exec /home/tim/spi/gdbremote/exp1: Exec format error.

Child exited with status 127
No program to debug. GDBserver exiting.
*****end of console output******

The binary is executable on the host side.
If I scp the file over it maintains the executable flag.
I cannot however debug since the batch process always overwrites the binary with the unexecutable image, so I have no workaround yet.

Report message to a moderator

Re: arm remote debug loses executable flag [message #1383858 is a reply to message #1292259]

Mon, 26 May 2014 15:22

Timothy Golden

Messages: 6
Registered: April 2014

Junior Member

There are several configuration issues that I've been working through, so in conjunction it is difficult to say with certainty, but I have a working system so:

This issue is in a remote debug environment using gdbserver on the target machine.
There is a line "Commands to execute before application" in the debug configurations main tab into which I entered:
chmod +x /home/tim/tmp/mcp
where mcp is the binary executable on the target machine, passing through an ssh connection.

caveat:
there was also a version mismatch between the development platform's gdb version versus the target machines version of gdbserver. Both machines were running debian wheezy, which would seem to be a sure match, but it turns out there was a minor version mismatch. I recompiled gdb from source code on my laptop which is my development system. This requires attention to cross-compilation options within the autotools system, which will actually be producing the binary file
arm-linux-gnueabi-gdb .

- Tim

Report message to a moderator

Previous Topic:	Symbol could not be resolved Issue
Next Topic:	Newbie question, my 2nd program. Is a new project for a new program?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 12:47:44 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter