Segmentation fault when no relocatables are given

[GoogleCodeExporter]

What steps will reproduce the problem?
ld.mcld -m elf32ltsmip --sysroot=<dir> -lc -o test

What is the expected output? 
Nothing

What do you see instead?
Segmentation fault

Original issue reported on code.google.com by ras46....@gmail.com on 25 Apr 2013 at 7:08

[GoogleCodeExporter]

It looks like the fault can reproduce only on mips backend. I will try to fix 
it.

Original comment by LubaTang on 26 Apr 2013 at 6:57

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by LubaTang on 26 Apr 2013 at 7:05

[GoogleCodeExporter]

Hi, Simon,

I find the bug happens in the scene:
- libc.so has __GLOBAL_OFFSET_TABLE__ symbol. (LoC 368 is not NULL)
- We do not have any input object files. in Mips, the global offset table is 
empty.
- seg fault occurs when Mips backend read GOT entries. Since GOT is empty, the 
entry is illegal. (LoC 367, *(m_pGOT->begin()))

365 void MipsGNULDBackend::defineGOTSymbol(IRBuilder& pBuilder)
366 {
367   // define symbol _GLOBAL_OFFSET_TABLE_
368   if ( m_pGOTSymbol != NULL ) {
369     pBuilder.AddSymbol<IRBuilder::Force, IRBuilder::Unresolve>(
370                      "_GLOBAL_OFFSET_TABLE_",
371                      ResolveInfo::Object,
372                      ResolveInfo::Define,
373                      ResolveInfo::Local,
374                      0x0, // size
375                      0x0, // value
376                      FragmentRef::Create(*(m_pGOT->begin()), 0x0),
377                      ResolveInfo::Hidden);
378   }

x86 and ARM backend do not have this fault because x86 and ARM GOT never be 
empty. They reserves some entries.

How do I handle with this issue in Mips backend? Just check whether GOT is 
empty or not. If GOT is empty, then do nothing in 
MipsLDBackend::defineGOTSymbol()? Is this the right way to handle empty GOT?

Best regards,
Luba

Original comment by LubaTang on 26 Apr 2013 at 9:06

[GoogleCodeExporter]

Hi Luba,

We should define _GLOBAL_OFFSET_TABLE_ if GOT is not empty. In other words if 
m_pGOT->hasGOT1() returns true. So your suggestion looks correct.

Original comment by si...@atanasyan.com on 26 Apr 2013 at 9:26

[GoogleCodeExporter]

Big thanks! I will do it by your suggestion.

Original comment by LubaTang on 29 Apr 2013 at 2:37

[GoogleCodeExporter]

Hi, Simon,

I found in GNU ld, Mips backend will reserve 8 bytes for GOT. Should we reserve 
GOT entries in GOT0?

Original comment by LubaTang on 29 Apr 2013 at 11:31

[GoogleCodeExporter]

Hi Luba,

It is not necessary. If the second entry is not equal to 0x80000000, loader 
considers this entry as a regular GOT entry. If this entry is equal to 
0x80000000, loader assumes that it can use this entry to store "module 
pointer". This is a GNU extension to MIPS ABI. We do not support it in MCLinker 
yet so we should not reserve the second GOT entry.

Original comment by si...@atanasyan.com on 29 Apr 2013 at 12:22

[GoogleCodeExporter]

Hi, Simon,

I try to resolve this issue at Revision 92f60e6f8397
If you have any comments, please kindly let me know.
If you think the patch is right, then just set this issue as Fixed.

Big thanks,
Luba

Original comment by LubaTang on 29 Apr 2013 at 12:25

[GoogleCodeExporter]

The patch is looking good.

Original comment by si...@atanasyan.com on 29 Apr 2013 at 1:42

• Changed state: Fixed