C expert needed

Started by Pelican, May 30, 2015, 09:00:25 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Pelican

Hi all,

It's completely not related to ML developing but I hope somebody here can help me with this problem.

There is a mini computer called Rasberry Pi 2. It runs linux (debian wheezy) and I would like to use the hardware IO ports of it from Lazarus (free pascal compiler and ide).
There is guy who developed a software library called wiringPi with C source.
Until now I used the previous model of Raspberry Pi and an old version of wiringPi's object file with a Pascal wrapper I wrote for it.
Right now this old version cannot work because the hardware changes of the Raspberry Pi 2, so I need the new version of wiringPi.
And the problem starts here: If I build the newer wiringPi from the sources the new object file contains several strange symbol like __aeabi_idiv, __aeabi_idivmod, etc.
When I try to use my wrapper with this new object file the pascal linker cannot handles this symbols, so it fails on it:
/usr/bin/ld.bfd: wiringPi.o undefined reference to symbol '__aeabi_idiv@@GCC3.5'
//lib/arm-linux-gnueabihf/libgcc_s.so.1: error adding symbols: DSO missing from command line


I peek inside the object file with objdump -t and see this symbol as
00000000    *UND*  __aeabi_idiv

Also I see it in the libgcc_s.so.1 with objdump -T
0000f950 g    DF .text  00000000  GCC_3.5     __aeabi_idiv

I tried to remove this strange symbols from the object file with objcopy --strip-symbol but it said it not stripped because it is named in a relocation.

I tried to search on the web and find not too much but I feel this is something similar to it:
http://glandium.org/blog/?p=2510

Is there any way to create this .o file without these __aeabi stuff?

I have no idea how I can solve this so please give me some clue if you are more familiar with these things.
Thanks in advance.


Edit FYI:
I use this Raspi to control a camera through Wifi and not just the camera itself but some servo motor which turns the focus wheel and change the aperture during a long exposition shot and remote control several flash units by radio.
EOS 7D Mark II, EOS 7D, EOS 5, EOS 100 + lenses (10mm to 300mm), 600EX, 550EX, YN600EX x 3
EOScard, EOS DSLR firmwares, ARMu, NiControl, etc.: http://pel.hu/down

eduperez

AFAIK:

Those symbols are the functions for the integer division and integer modulus. You cannot just remove them from the .o file, because some code in that file needs those functions; unless such code can be easily removed from wiringPi, you have to either statically link those functions into your .o file, or tell your wrapper how to search those symbols at libgcc. In my humble opinion, it looks like your wrapper is not properly configured.

g3gg0

OT-OT:
i can recommend NodeMCU (http://en.wikipedia.org/wiki/NodeMCU)
the processor is the same chip as the wifi chip, so you have a small footprint.
see e.g. http://i.imgur.com/FY98xHX.jpg

programming language is LUA or C if you want to program the ESP directly.

why i like it?
the module is $3 on ebay
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Pelican

Quote from: eduperez on June 01, 2015, 11:57:28 PM
In my humble opinion, it looks like your wrapper is not properly configured.
What do you mean? How can I properly configure my wrapper? I thought the wrapper doesn't do anything but point to a function in an object file.
And also I thought if the object file contains extra functions that I don't link then it doesn't affect my program.

Quote from: g3gg0 on June 02, 2015, 12:32:26 AM
OT-OT:
i can recommend NodeMCU (http://en.wikipedia.org/wiki/NodeMCU)
the processor is the same chip as the wifi chip, so you have a small footprint.
Thanks, I have a wifi module (ESP-03) with that chip, but as far as I know that is not in the same ballpark as the RasPi.
EOS 7D Mark II, EOS 7D, EOS 5, EOS 100 + lenses (10mm to 300mm), 600EX, 550EX, YN600EX x 3
EOScard, EOS DSLR firmwares, ARMu, NiControl, etc.: http://pel.hu/down

g3gg0

sure, it hasnt even close that good performance as the RasPi.
but for simple control things its enough. :)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

eduperez

Quote from: Pelican on June 02, 2015, 02:43:51 PM
What do you mean? How can I properly configure my wrapper? I thought the wrapper doesn't do anything but point to a function in an object file.
And also I thought if the object file contains extra functions that I don't link then it doesn't affect my program.

If I am not mistaken, your .o file contains references to some external functions (__aeabi_idiv, __aeabi_divmod), and the message means your linker has trouble resolving those references. It seems to be able to find those functions at "/lib/arm-linux-gnueabihf/libgcc_s.so.1", however; but then it fails when adding them. Could you post more info here about that wrapper, please?

Quote from: g3gg0 on June 02, 2015, 12:32:26 AM
OT-OT:
i can recommend NodeMCU (http://en.wikipedia.org/wiki/NodeMCU)
the processor is the same chip as the wifi chip, so you have a small footprint.
see e.g. http://i.imgur.com/FY98xHX.jpg

programming language is LUA or C if you want to program the ESP directly.

why i like it?
the module is $3 on ebay

Just whoa!!! You have opened a whole new world to me; many thanks, but my wife is going to hate you now.

g3gg0

Quote from: eduperez on June 02, 2015, 11:34:44 PM
many thanks, but my wife is going to hate you now.

i guess i can live with that ;D
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

g3gg0

on topic:
these __aeabi_ functions are the ARM EABI interface functions for "idiv" and similar.
they are used - as already described - to execute integer division.
your compiler does not insert the integer division ARM code for every "/" you make, but instead makes a call
to the generic division function it expects to be visible during linking.

short: compiler insists that this function exists.

usually the linker will find the function when you link to the libgcc (linker option -lgcc) you use on this target.
the linker then can find these function.

you could also implement that function on your own.
iirc when googling, you could find some reference implementation of them.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Pelican

I simplified the sources to a minimum level.
As you can see the main unit not even calls any wiringPi functions, only lists the unit in the uses.
For the linker is nothing to do with the wiringPi.o but it fails on it.
If I change the object file path to point to the previous version of the object file then everything is fine.

The main program:
unit Main;

{$mode objfpc}{$H+}

interface

uses Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls,  WiringPi;

type

  { TfMain }

  TfMain = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;

var
  fMain: TfMain;

implementation

{$R *.lfm}

{ TfMain }

procedure TfMain.Button1Click(Sender: TObject);
begin
//  wiringPiSetup;
end;

end.



The wrapper for the wiringPi:

unit wiringPi;
{$link /home/pi/wiringPi/wiringPi/wiringPi.o}
{$linklib c}

interface

  Function wiringPiSetup:longint;cdecl;external;

end.


Quote from: g3gg0 on June 03, 2015, 12:09:06 AM
you could also implement that function on your own.
iirc when googling, you could find some reference implementation of them.
I found some source for these __aeabi functions but what could I do with them? I tried to change the wiringPi makefile and put these sources in it but nothing happened.

Makefile section where I tried to put the __aeabi_idiv.c and other sources
SRC = wiringPi.c \
wiringSerial.c wiringShift.c \
piHiPri.c piThread.c \
wiringPiSPI.c wiringPiI2C.c \
softPwm.c softTone.c \
mcp23008.c mcp23016.c mcp23017.c \
mcp23s08.c mcp23s17.c \
sr595.c \
pcf8574.c pcf8591.c \
mcp3002.c mcp3004.c mcp4802.c mcp3422.c \
max31855.c max5322.c \
sn3218.c \
drcSerial.c \
wpiExtensions.c


wiringPi source:
https://git.drogon.net/?p=wiringPi;a=snapshot;h=5edd177112c99416f68ba3e8c6c4db6ed942e796;sf=tgz
EOS 7D Mark II, EOS 7D, EOS 5, EOS 100 + lenses (10mm to 300mm), 600EX, 550EX, YN600EX x 3
EOScard, EOS DSLR firmwares, ARMu, NiControl, etc.: http://pel.hu/down

eduperez

I guess there is new code in WiringPi, that uses integer division / module functions; so the .o file now contains references to __aeabi_* functions, and the linker has trouble resolving them.
Could you post here the whole Makefile that produces the error, please?

Pelican

Thanks for everybody.
Finally I found the solution on another forum where somebody write similar pascal wrapper but he not linked the wiringpi.o directly but just through the installed library:

{$linklib c}
{$linklib libwiringPi}

And this way it is just working.
EOS 7D Mark II, EOS 7D, EOS 5, EOS 100 + lenses (10mm to 300mm), 600EX, 550EX, YN600EX x 3
EOScard, EOS DSLR firmwares, ARMu, NiControl, etc.: http://pel.hu/down