search

cwalls251 / iphone-dev

Automatically exported from code.google.com/p/iphone-dev
0 stars 0 forks source link

Linking problems on Linux that cause strip to produce corrupt objects #29

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
The toolchain, when built on Linux, incorrectly links libgcc_s.10.4.dylib.tmp, 
resulting in a corrupt 
binary when run through strip (the magic number is wrong!) Unknown why this 
occurs.

On Linux some symbols in libgcc_s.10.4.dylib.tmp are not marked external (div0, 
etc), while they 
are on OS X. Maybe this has something to do with it?

Original issue reported on code.google.com by nightwat...@gmail.com on 13 Sep 2007 at 8:06

GoogleCodeExporter commented 8 years ago

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 8:07

GoogleCodeExporter commented 8 years ago 
The corruption is happening here:

check_indirect_symtab (arch=0x3001c0, member=0x0, object=0x300290, nitems=2, 
reserved1=30, 
section_type=6, contents=0x6e000 "?m", symbols=0x76080, symbols64=0x0, 
nsyms=303, strings=0x77430 
"", missing_reloc_symbols=0xbfffef3c, host_byte_sex=LITTLE_ENDIAN_BYTE_SEX) at 
strip.c:2019

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 8:21

GoogleCodeExporter commented 8 years ago 
after running indent on the file so I can read it, it's:

0x00002245 in check_indirect_symtab (arch=0x3001c0, member=0x0, 
object=0x300290, nitems=2, 
reserved1=30, section_type=6, contents=0x6e000 "?m", symbols=0x76080, 
symbols64=0x0, nsyms=303, 
strings=0x77430 "", missing_reloc_symbols=0xbfffef3c, 
host_byte_sex=LITTLE_ENDIAN_BYTE_SEX) at 
strip.c:1978
1978                        *(uint32_t *) (contents + k * 4) = value;

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 8:30

GoogleCodeExporter commented 8 years ago 
Possibly related to a faulty __attribute__((hidden)).

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 10:24

GoogleCodeExporter commented 8 years ago 
Doesn't always seem to occur. Hmmmm.

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 11:38

GoogleCodeExporter commented 8 years ago 
Rebuilt and the problem went away -- rebuild again and it showed up. Even after 
a
"successful" build, many apps are randomly crashing (ruby interpreter for 
example)

Original comment by x...@hdm.io on 16 Sep 2007 at 4:42

GoogleCodeExporter commented 8 years ago 
Could you file the crashes as separate bugs, with stack backtraces? Thanks.

Original comment by nightwat...@gmail.com on 16 Sep 2007 at 2:27

GoogleCodeExporter commented 8 years ago 
Any ideas for obtaining a stack backtrace from a native app? I didn't see an 
easy way
to build gcc.

Original comment by x...@hdm.io on 16 Sep 2007 at 4:50

GoogleCodeExporter commented 8 years ago 
On the iPhone, /var/logs/CrashReporter/LatestCrash.plist has a backtrace; you 
can also try vmutils.framework in 
PrivateFrameworks on the iPhone (class-dump it).

Original comment by nightwat...@gmail.com on 19 Sep 2007 at 10:34

GoogleCodeExporter commented 8 years ago 
Filed as bug #44.

Original comment by x...@hdm.io on 19 Sep 2007 at 10:49

GoogleCodeExporter commented 8 years ago 
I got around this by skipping the stripping of libgcc_s.  

run make.  wait until make stops with errors about arm-apple-darwin-lipo and
libgcc_s.10.4.dylib.  Then run:

# cd llvm-gcc-4.0-iphone/gcc
# arm-apple-darwin-lipo -output libgcc_s.10.4.dylib -create libgcc_s.1.dylib.tmp
# arm-apple-darwin-lipo -output libgcc_s.10.5.dylib -create libgcc_s.1.dylib.tmp
# cd ..

and then make and sudo make install to finish up.  

Apps now compile for me on an x86 Linux box!

Original comment by benjie on 9 Oct 2007 at 11:51