Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 10:30:05AM +0200, Bastian Blank wrote:
> D-I may be also affected and mklibs needs to pull in libgcc_s.so.1
> always if it catches a glibc.
The attached mklibs patch always adds libgcc for old-abi arm.
Bastian
--
Well, Jim, I'm not much of an actor either.
Index: debian/control
===
--- debian/control (revision 108)
+++ debian/control (working copy)
@@ -8,7 +8,7 @@
Package: mklibs
Architecture: all
-Depends: python, binutils, gcc, mklibs-copy (>= 0.1.21)
+Depends: python, binutils, gcc, mklibs-copy (>= ${source:Version})
Recommends: libc6-pic | libc6.1-pic
Description: Shared library reduction script
mklibs produces cut-down shared libraries that contain only the
Index: src/mklibs-copy.py
===
--- src/mklibs-copy.py (revision 108)
+++ src/mklibs-copy.py (working copy)
@@ -65,6 +65,13 @@
return result
+def elf_header(obj):
+if not os.access(obj, os.F_OK):
+raise "Cannot find lib: " + obj
+output = command("mklibs-readelf", "--print-elf-header", obj)
+s = [int(i) for i in output[0].split()]
+return {'class': s[0], 'data': s[1], 'machine': s[2], 'flags': s[3]}
+
# Return a set of rpath strings for the passed object
def rpath(obj):
if not os.access(obj, os.F_OK):
@@ -278,6 +285,11 @@
previous_pass_libraries = libraries
+# WORKAROUND: Always add libgcc on old-abi arm
+header = elf_header(find_lib(libraries.copy().pop()))
+if header['machine'] == 40 and header['flags'] & 0xff00 == 0:
+libraries.add('libgcc_s.so.1')
+
# reduce libraries
for library in libraries:
so_file = find_lib(library)
Index: src/mklibs-readelf/main.cpp
===
--- src/mklibs-readelf/main.cpp (revision 112)
+++ src/mklibs-readelf/main.cpp (working copy)
@@ -18,6 +18,7 @@
static struct option const long_opts[] =
{
+ {"print-elf-header", no_argument, 0, 'e'},
{"print-interp", no_argument, 0, 'i'},
{"print-needed", no_argument, 0, 'n'},
{"print-rpath", no_argument, 0, 'R'},
@@ -33,6 +34,7 @@
enum command
{
+ COMMAND_PRINT_ELF_HEADER,
COMMAND_PRINT_INTERP,
COMMAND_PRINT_NEEDED,
COMMAND_PRINT_RPATH,
@@ -41,6 +43,15 @@
COMMAND_PRINT_SYMBOLS_UNDEFINED,
};
+static void process_elf_header (Elf::file *file)
+{
+ std::cout
+<< (unsigned int) file->get_class () << ' '
+<< (unsigned int) file->get_data () << ' '
+<< file->get_machine () << ' '
+<< file->get_flags () << '\n';
+}
+
static void process_dynamics (Elf::section_type
*section, int64_t tag)
{
for (std::vector::const_iterator it = section->get_dynamics
().begin (); it != section->get_dynamics ().end (); ++it)
@@ -108,6 +119,9 @@
switch (cmd)
{
+case COMMAND_PRINT_ELF_HEADER:
+ process_elf_header (file);
+ break;
case COMMAND_PRINT_INTERP:
if (segment_interp)
std::cout << segment_interp->get_interp () << '\n';
@@ -166,12 +180,15 @@
program_name = argv[0];
- while ((c = getopt_long (argc, argv, "inpRsu", long_opts, NULL)) != -1)
+ while ((c = getopt_long (argc, argv, "einpRsu", long_opts, NULL)) != -1)
{
switch (c)
{
case 0:
break;
+ case 'e':
+cmd = COMMAND_PRINT_ELF_HEADER;
+break;
case 'i':
cmd = COMMAND_PRINT_INTERP;
break;
Index: src/mklibs-readelf/elf.cpp
===
--- src/mklibs-readelf/elf.cpp (revision 105)
+++ src/mklibs-readelf/elf.cpp (working copy)
@@ -150,6 +150,7 @@
this->machine = convert<_data, typeof (ehdr->e_machine )> ()
(ehdr->e_machine);
this->phoff = convert<_data, typeof (ehdr->e_phoff)> ()
(ehdr->e_phoff);
this->shoff = convert<_data, typeof (ehdr->e_shoff)> ()
(ehdr->e_shoff);
+ this->flags = convert<_data, typeof (ehdr->e_flags)> ()
(ehdr->e_flags);
this->phentsize = convert<_data, typeof (ehdr->e_phentsize)> ()
(ehdr->e_phentsize);
this->phnum = convert<_data, typeof (ehdr->e_phnum)> ()
(ehdr->e_phnum);
this->shentsize = convert<_data, typeof (ehdr->e_shentsize)> ()
(ehdr->e_shentsize);
Index: src/mklibs-readelf/elf.hpp
===
--- src/mklibs-readelf/elf.hpp (revision 105)
+++ src/mklibs-readelf/elf.hpp (working copy)
@@ -31,15 +31,15 @@
namespace Elf
{
- class file_class_32 { public: static const unsigned int id = 1; };
- class file_class_64 { public: static const unsigned int id = 2; };
- class file_data_2LSB { public: static const unsigned int id = 1; };
- class file_data_2MSB { public: static const unsigned int id = 2; };
+ class file_class_32 { public: static const uint8_t id = 1; };
+ class file_class_64 { public: static const uint8_t id = 2; };
+ class file_data_2LSB {
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 11:49:54AM +0200, Bastian Blank wrote: > On Wed, May 30, 2007 at 11:31:35AM +0200, Bastian Blank wrote: > > On Wed, May 30, 2007 at 11:19:38AM +0200, Aurelien Jarno wrote: > > > What I don't understand is why /sbin/init on arm now uses threads? > > It is /bin/sh, which should be busybox. > > And it does not use pthread at all. It may be usefull to get a > backtrace. Yes. I suspect the relevant wrapped functions are called more frequently on ARM. This is ARM old-ABI, so it uses SJLJ exception handling; that means the _Unwind_* functions are called around functions that might throw, not just when an exception is thrown. Note, that was exceptions, not threads. This code is in libc and libpthread. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 11:31:35AM +0200, Bastian Blank wrote: > On Wed, May 30, 2007 at 11:19:38AM +0200, Aurelien Jarno wrote: > > What I don't understand is why /sbin/init on arm now uses threads? > It is /bin/sh, which should be busybox. And it does not use pthread at all. It may be usefull to get a backtrace. Bastian -- Without facts, the decision cannot be made logically. You must rely on your human intuition. -- Spock, "Assignment: Earth", stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 11:19:38AM +0200, Aurelien Jarno wrote: > What I don't understand is why /sbin/init on arm now uses threads? It is /bin/sh, which should be busybox. > It is clear that we miss a dependency on libgcc1/libgcc2/libgcc4, but > unfortunately I am not sure there is another way to fix that. I don't think that ld is able to process recursive lib deps. So there is no other fix. Bastian -- He's dead, Jim. -- McCoy, "The Devil in the Dark", stardate 3196.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libc dlopening libgcc on arm
Bastian Blank a écrit : > On Wed, May 30, 2007 at 10:30:05AM +0200, Bastian Blank wrote: >> This code is located in libpthread and consist of direct wrappers around >> libgcc functions. Isn't it possible to just correctly link against >> libgcc instead of this dlopen stunt? As libgcc needs libc, it is not >> possible to do that for libc, but libpthread should work, or do I miss >> something? > > Yes I did. The code is spread over the complete libc.so.6 depending on > the correct architecture. > What I don't understand is why /sbin/init on arm now uses threads? It is clear that we miss a dependency on libgcc1/libgcc2/libgcc4, but unfortunately I am not sure there is another way to fix that. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 10:30:05AM +0200, Bastian Blank wrote: > This code is located in libpthread and consist of direct wrappers around > libgcc functions. Isn't it possible to just correctly link against > libgcc instead of this dlopen stunt? As libgcc needs libc, it is not > possible to do that for libc, but libpthread should work, or do I miss > something? Yes I did. The code is spread over the complete libc.so.6 depending on the correct architecture. Bastian -- Violence in reality is quite different from theory. -- Spock, "The Cloud Minders", stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 09:27:10AM +0200, Aurelien Jarno wrote: > The same code is also present on glibc 2.3.6 for nptl builds. So at > least amd64 is using it in etch for the initrd. Yes. But it is only used sometimes. This code is located in libpthread and consist of direct wrappers around libgcc functions. Isn't it possible to just correctly link against libgcc instead of this dlopen stunt? As libgcc needs libc, it is not possible to do that for libc, but libpthread should work, or do I miss something? D-I may be also affected and mklibs needs to pull in libgcc_s.so.1 always if it catches a glibc. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
