Fail to link crt1.o when generating ARM executable

[GoogleCodeExporter]

Steps for reproduce the problem:
(Using llvm r152063 and  clang r152062)

main.c
---------------
main() {
  return 0;
}
---------------

1.clang -emit-llvm  -target arm-none-linux-eabi -c  main.c  -o main.bc

2.llvm-mcld  -filetype=obj  -march=arm -mtriple="arm-none-linux-gnueabi" -dB  
main.bc -o main.o

3.llvm-mcld  -filetype=exe  -march=arm -mtriple="armv7-none-linux-gnueabi" 
main.o -o main.exe  arm_codesourcery/arm-none-linux-gnueabi/libc/usr/lib/crt1.o

error message:
WARNING: can not open search directory: `-L=/system/lib'.
WARNING: Exception handling has not been fully supported yet.
section `.ARM.exidx'.
Stack dump:
0.      Running pass 'Function Pass Manager' on module 'Empty Module'.
Segmentation fault

Original issue reported on code.google.com by jush....@gmail.com on 2 May 2012 at 7:12

[GoogleCodeExporter]

The segmentation fault occur because when emit relocation section, no output 
symbol is found in SymIndexMap. Currently we do not handle emitting executable 
in GNULDBackend::isDynamicSymbol. 

Original comment by mysekki on 4 May 2012 at 9:34

[GoogleCodeExporter]

We discussed about the symbols of executable program with Google gold linker's 
Doug Kwan  <dougkwan@google.com>. By the discussion, I think we can boldly let 
all external symbols go into the dynamic symbol table.

Is there anyone can take care of the issue? And change the rule of 
GNULDBackend::isDynamicSymbol()?

Original comment by LubaTang on 4 May 2012 at 9:40

[GoogleCodeExporter]

Fix in Rev:edb9b0edaf78. Add rule to emit symbols for executable files (the 
rule is the same as emitting shared object)
Now it should not break when generating executable.

Original comment by mysekki on 4 May 2012 at 9:57

• Changed state: Fixed

[GoogleCodeExporter]

I have a question. Should we let all reserved symbols be dynamic symbols?
I mean:

if (pSymbol.reserved())
  return true;

Original comment by LubaTang on 7 May 2012 at 2:50

[GoogleCodeExporter]

Issue 31 has been merged into this issue.

Original comment by LubaTang on 7 May 2012 at 2:51

[GoogleCodeExporter]

I think that let only the reserved symbols be the dynamic symbols won't cause 
problem now, but that might not what we want. The dynamic symbols for 
executable may be either 
(1) The symbols used by dynamic relocations
(2) All the external symbols (while this may emit more symbols than (1), but 
it's an easier way)

While in current design, the "reserved symbols" may contains relocation 
symbols, GOT symbols, PLT symbols, ..., which is defined by targets their own. 
The meaning of "reserved symbols" differ from each target. I'm considered that 
uses "reserved symbols" to judge the dynamic symbols is confusing.

Original comment by mysekki on 7 May 2012 at 3:50