Experimental Physics and Industrial Control System
|
Hi,
I have some additional information on my problem
(found on
http://www.redhat.com/docs//manuals/enterprise/RHEL-4-Manual/gnu-assembler/cris-syntax.html,
thanks to B.Kolb)
When generating position-independent code (SVR4
PIC) for use in cris-axis-linux-gnu shared libraries, symbol
suffixes are used to specify what kind of run-time symbol lookup
will be used, expressed in the object as different relocation types. Usually, all absolute
symbol values
must be located in a table, the global
offset table,
leaving the code position-independent; independent of values of
global symbols and independent of the address of the code. The
suffix modifies the value of the symbol, into for example an
index into the global offset table where the real symbol value
is entered, or a PC-relative value, or a value relative to the
start of the global offset table. [...]
- GOT
-
Attaching this suffix to a symbol in an instruction causes
the
symbol to be entered into the global offset table. The value
is
a 32-bit index for that symbol into the global offset table.
The name of the corresponding relocation is R_CRIS_32_GOT. [...]
[...]
- PLT
-
This suffix is used for function symbols. It causes a procedure linkage table, an array of
code
stubs, to be
created at the time the shared object is created or linked
against, together with a global offset table entry. The
value
is a pc-relative offset to the corresponding stub code in
the
procedure linkage table. This arrangement causes the
run-time
symbol resolver to be called to look up and set the value of
the
symbol the first time the function is called (at latest;
depending environment variables). It is only safe to leave
the
symbol unresolved this way if all references are function
calls.
The name of the relocation is R_CRIS_32_PLT_PCREL.
[...]
[...]
- GOTPLT
-
Similar to PLT, but the value of
the
symbol is a 32-bit
index into the global offset table. This is somewhat of a
mix
between the effect of the GOT and
the PLT suffix;
the difference to GOT is that
there will be a
procedure
linkage table entry created, and that the symbol is assumed
to
be a function entry and will be resolved by the run-time
resolver as with PLT. The
relocation is R_CRIS_32_GOTPLT.[...]
... so does this mean shared libraries are used although
-Wl,-Bstatic -static-libgcc
is used?
Again any help is welcome.
Peter
Dr. Peter Zumbruch wrote:
Hello everybody,
I am trying to cross compile and link an application based on
stream
device and asyn
with patched base 3.14.10 on a linux-x86_64 system with the
linux-cris_v10 as target.
Stream and Asyn have been compiled for the host and target
architectures.
When building the application the final linking for the target
failes
with this command
(which I just split up for better reading, and paths shortened
<..>):
cris-g++ -o streamHadcon
-Wl,-Bstatic -static-libgcc
-Wl,--strip-all
-L<IOC_TOP>/lib/linux-cris_v10
-L<EPICS_HOME>/base/lib/linux-cris_v10
-L<EPICS_HOME>/modules/soft/StreamDevice/lib/linux-cris_v10
-L<EPICS_HOME>/modules/soft/asyn/asyn-4.11a/lib/linux-cris_v10
-Wl,-rpath,<IOC_TOP>/lib/linux-cris_v10
-Wl,-rpath,<EPICS_HOME>/base/lib/linux-cris_v10
-Wl,-rpath,<EPICS_HOME>/modules/soft/StreamDevice/lib/linux-cris_v10
-Wl,-rpath,<EPICS_HOME>/modules/soft/asyn/asyn-4.11a/lib/linux-cris_v10
-L<AXIS_TOP>/target/cris-axis-linux-gnu/lib
-L<AXIS_TOP>/target/cris-axis-linux-gnu/usr/lib
streamHadcon_registerRecordDeviceDriver.o streamHadconMain.o
-lstreamHadconSupport
-lrecIoc
-lsoftDevIoc
-lmiscIoc
-lrsrvIoc
-ldbtoolsIoc
-lasIoc
-ldbIoc
-lregistryIoc
-ldbStaticIoc
-lca
-lCom
-lstream
-lasyn
-lpthread
-lm
-lrt
resulting in this output:
<EPICS_ASYN>/lib/linux-cris_v10/libasyn.a(devAsynInt32.o):
In
function `getIoIntInfo':
epicsTypeClass/../../asyn/devEpics/devAsynInt32.c:288: undefined
reference to `epicsRingBytesCreate'
[..]/cris-axis-linux-gnu/bin/ld:
<EPICS_ASYN>/lib/linux-cris_v10/libasyn.a(devAsynInt32.o):
No PLT
for relocation R_CRIS_32_GOTPLT against symbol
`epicsRingBytesCreate'
from .text section
[..]/cris-axis-linux-gnu/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
Notes:
- But 'epicsRingBytesCreate' is defined in
libasyn.a(devAsynInt32.o),
(cris-)nm gives consistent results
- Unfortunately in addition I do not fully get the meaning of the
error
- It does compile for linux-x86_64
- base itself needed an independent patch for _64 architecture in
base
CONFIG.linux-x86_64.linux-cris(_v10/32) copy linux-x86 (to be
committed
soon)
Since I did the port of EPICS to cris,
has anybody else seen such a response or something similar when
cross
building an application?
Any help appreciated,
Thanks, Peter
--
Dr. rer. nat. Peter W. Zumbruch
EE - department / Controls group / GSI
E-Mail: P.Zumbruch_at_gsi.de
Tel: +49-(6159)-71-1435 / Fax: +49-(6159)-71-2986
GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1 / D-64291 Darmstadt / www.gsi.de
Gesellschaft mit beschränkter Haftung
Sitz der Gesellschaft: Darmstadt
Handelsregister: Amtsgericht Darmstadt, HRB 1528
Geschäftsführung: Professor Dr. Dr. h.c. Horst Stöcker,
Christiane Neumann, Dr. Hartmut Eickhoff
Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph,
Stellvertreter: Ministerialdirigent Dr. Rolf Bernhardt
|
- References:
- No PLT for relocation Dr. Peter Zumbruch
- Navigate by Date:
- Prev:
No PLT for relocation Dr. Peter Zumbruch
- Next:
Re: No PLT for relocation Dr. Peter Zumbruch
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
No PLT for relocation Dr. Peter Zumbruch
- Next:
Re: No PLT for relocation Dr. Peter Zumbruch
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|