dl_iterate_phdr missing in libc

[Carmelo AMOROSO]

Hi All,
I'm facing a problem when statically linking an app with
sh4-linux-uclibc-g++
caused by the missing symbol dl_iterate_phdr as below:

sh4-linux-uclibc-g++ -static main.c
/opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1/libgcc_eh.a(unwind-dw2-fde-glibc.o):
In function `_Unwind_Find_FDE':
/home/macaroni/users/products/stm2.3/build/packages/stm-cross-gcc-sh4_uclibc/BUILD/gcc-4.2.1/objdir/gcc/../../gcc/unwind-dw2-fde-glibc.c:430:
undefined reference to `dl_iterate_phdr'

Indeed the symbols is defined into the ld.so (not used when statically
linked) and into libdl.a
but, being libgcc_eh.a requiring this symbol, it will not find it even
if -ldl is passed.

I've checked glibc and found that dl_iterate_phdr in into libc instead
od ld.so and libdl.a
A comment in uclibc dl-elf.c says explicitly:

"we want this in ld.so and libdl.a but nowhere else"

Could someone explain this to me ? I need to fix immediately into
uclibc-nptl sh4
adding the symbol into the libc too, as it is required by an our
customer on production,
but I'd like to have a common fix also for the trunk.

Cheers,
Carmelo

[Carmelo Amoroso]

I forgot to specify that the implementation for the libc.a is different.

Post by Carmelo AMOROSO
Hi All,
I'm facing a problem when statically linking an app with
sh4-linux-uclibc-g++
sh4-linux-uclibc-g++ -static main.c
undefined reference to `dl_iterate_phdr'
Indeed the symbols is defined into the ld.so (not used when statically
linked) and into libdl.a
but, being libgcc_eh.a requiring this symbol, it will not find it even
if -ldl is passed.
I've checked glibc and found that dl_iterate_phdr in into libc instead
od ld.so and libdl.a
"we want this in ld.so and libdl.a but nowhere else"
Could someone explain this to me ? I need to fix immediately into
uclibc-nptl sh4
adding the symbol into the libc too, as it is required by an our
customer on production,
but I'd like to have a common fix also for the trunk.
Cheers,
Carmelo
_______________________________________________
uClibc mailing list
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

[Bernd Schmidt]

Post by Carmelo AMOROSO
Hi All,
I'm facing a problem when statically linking an app with
sh4-linux-uclibc-g++
sh4-linux-uclibc-g++ -static main.c
undefined reference to `dl_iterate_phdr'

We just configure our compilers not to use unwind-dw2-fde-glibc, but the
generic version.


Bernd

[Carmelo AMOROSO]

Post by Bernd Schmidt

Post by Carmelo AMOROSO
Hi All,
I'm facing a problem when statically linking an app with
sh4-linux-uclibc-g++
sh4-linux-uclibc-g++ -static main.c
undefined reference to `dl_iterate_phdr'

We just configure our compilers not to use unwind-dw2-fde-glibc, but the
generic version.
Bernd

Ok, but this is a way to overcome the issue. My questions were to
understand
the rationale behind uclibc current implementation.

Carmelo

[Carmelo Amoroso]

Post by Bernd Schmidt

Post by Carmelo AMOROSO
Hi All,
I'm facing a problem when statically linking an app with
sh4-linux-uclibc-g++
sh4-linux-uclibc-g++ -static main.c
undefined reference to `dl_iterate_phdr'

We just configure our compilers not to use unwind-dw2-fde-glibc, but the
generic version.
Bernd

Hi Bernd,

I read you reply better again... just to understand better.
Is the unwind-dw2-fde-glibc wrong/unusable for uclibc being strictly
based on some glibc features, or it's one of the possible
implementation ?
In case it's wrong/unusable, then should be worth add a patch to gcc
configuration into buildroot.


Thanks and regards,
Carmelo

[Mike Frysinger]

Post by Carmelo AMOROSO
I'm facing a problem when statically linking an app with
sh4-linux-uclibc-g++
sh4-linux-uclibc-g++ -static main.c
/opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1/libgc
/home/macaroni/users/products/stm2.3/build/packages/stm-cross-gcc-sh4_uclib
c/BUILD/gcc-4.2.1/objdir/gcc/../../gcc/unwind-dw2-fde-glibc.c:430: undefined
reference to `dl_iterate_phdr'

static is the devil ;)

Post by Carmelo AMOROSO
Indeed the symbols is defined into the ld.so (not used when statically
linked) and into libdl.a

yep

Post by Carmelo AMOROSO
but, being libgcc_eh.a requiring this symbol, it will not find it even
if -ldl is passed.

what a pain huh

Post by Carmelo AMOROSO
I've checked glibc and found that dl_iterate_phdr in into libc instead
od ld.so and libdl.a
"we want this in ld.so and libdl.a but nowhere else"
Could someone explain this to me ?

it's a symbol only used by symbol related stuff which is why we put it there.
the comment is to cover the fact we *dont* want it in say libdl.so.

Post by Carmelo AMOROSO
I need to fix immediately into uclibc-nptl sh4

isnt it always ?

Post by Carmelo AMOROSO
adding the symbol into the libc too, as it is required by an our
customer on production, but I'd like to have a common fix also for the
trunk.

looks like we'll need to relocate it to libc.a from libdl.a
-mike

[Carmelo Amoroso]

Post by Mike Frysinger

Post by Carmelo AMOROSO
I'm facing a problem when statically linking an app with
sh4-linux-uclibc-g++
sh4-linux-uclibc-g++ -static main.c
/opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1/libgc
/home/macaroni/users/products/stm2.3/build/packages/stm-cross-gcc-sh4_uclib
c/BUILD/gcc-4.2.1/objdir/gcc/../../gcc/unwind-dw2-fde-glibc.c:430: undefined
reference to `dl_iterate_phdr'

static is the devil ;)

Hi Mike,
yes, but it seems a lot of people in embedded world prefer it,
likely they have concerns on performance.

Post by Mike Frysinger

Post by Carmelo AMOROSO
Indeed the symbols is defined into the ld.so (not used when statically
linked) and into libdl.a

yep

Post by Carmelo AMOROSO
but, being libgcc_eh.a requiring this symbol, it will not find it even
if -ldl is passed.

what a pain huh

Post by Carmelo AMOROSO
I've checked glibc and found that dl_iterate_phdr in into libc instead
od ld.so and libdl.a
"we want this in ld.so and libdl.a but nowhere else"
Could someone explain this to me ?

it's a symbol only used by symbol related stuff which is why we put it there.
the comment is to cover the fact we *dont* want it in say libdl.so.

Post by Carmelo AMOROSO
I need to fix immediately into uclibc-nptl sh4

isnt it always ?

Post by Carmelo AMOROSO
adding the symbol into the libc too, as it is required by an our
customer on production, but I'd like to have a common fix also for the
trunk.

looks like we'll need to relocate it to libc.a from libdl.a
-mike

Yes, I don't want to keep it into libdl.a and libc.a, only ld.so and libc.a.
Anyway the dl_iterate_phdr implementation needs to handle the statically linked application too,
as glibc actually does. I'll provide a patch for review soon.

Further, basing on Bernds suggestion, I'm building gcc with a patch to use generic unwind-dw2
implementation. Anyway we are discussing what is the best solution for us.

Thanks,
Carmelo

Post by Mike Frysinger
------------------------------------------------------------------------
_______________________________________________
uClibc mailing list
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

[Mike Frysinger]

Post by Carmelo Amoroso

Post by Mike Frysinger

Post by Carmelo AMOROSO
I'm facing a problem when statically linking an app with
sh4-linux-uclibc-g++
sh4-linux-uclibc-g++ -static main.c
/opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1/li
/home/macaroni/users/products/stm2.3/build/packages/stm-cross-gcc-sh4_uc
undefined reference to `dl_iterate_phdr'

static is the devil ;)

yes, but it seems a lot of people in embedded world prefer it,
likely they have concerns on performance.

sounds more like misinformation on their part ... i wonder if they realize
that uClibc by default builds libc.a as PIC ... oh well, retraining customers
is sadly not feasible in today's world it would seem

Post by Carmelo Amoroso

Post by Mike Frysinger

Post by Carmelo AMOROSO
adding the symbol into the libc too, as it is required by an our
customer on production, but I'd like to have a common fix also for the
trunk.

looks like we'll need to relocate it to libc.a from libdl.a

Yes, I don't want to keep it into libdl.a and libc.a, only ld.so and
libc.a. Anyway the dl_iterate_phdr implementation needs to handle the
statically linked application too, as glibc actually does. I'll provide a
patch for review soon.

i thought ours already did ... otherwise, putting it into libdl.a is bad as
it's simply a placebo for people.

Post by Carmelo Amoroso
Further, basing on Bernds suggestion, I'm building gcc with a patch to use
generic unwind-dw2 implementation. Anyway we are discussing what is the
best solution for us.

that is a short term fix rather than long term i would think
-mike

[Carl SHAW]

Post by Carmelo Amoroso

Post by Mike Frysinger

Post by Carmelo AMOROSO
I'm facing a problem when statically linking an app with
sh4-linux-uclibc-g++
sh4-linux-uclibc-g++ -static main.c
/opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1/libgc
/home/macaroni/users/products/stm2.3/build/packages/stm-cross-gcc-sh4_uclib
c/BUILD/gcc-4.2.1/objdir/gcc/../../gcc/unwind-dw2-fde-glibc.c:430: undefined
reference to `dl_iterate_phdr'

static is the devil ;)

Hi Mike,
yes, but it seems a lot of people in embedded world prefer it,
likely they have concerns on performance.

I think the reason is that traditionally embedded boxes only contained a
single monolithic application (and in the past not even an OS). i.e.
there are no root file system utilities like "ls", etc. and the
application replaces the init process. This was to reduce system
complexity and keep the software as small as possible (FLASH memory is
relatively expensive).

Except for really basic systems, even embedded boxes these days are
becoming too complicated for such a model so this approach is dying out...

Besides, I think that the performance difference between dynamic and
static on SH4 will be tiny given its 16 bit instruction set (load/stores
via addresses in registers, branch instructions are all relative, etc.)
- - only the dynamic loader would cause a small overhead on startup and
for a simple application this is not worth the problems!

Carl