Closed GoogleCodeExporter closed 9 years ago
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
Original comment by LubaTang
on 26 Apr 2013 at 7:05
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
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
Big thanks! I will do it by your suggestion.
Original comment by LubaTang
on 29 Apr 2013 at 2:37
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
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
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
The patch is looking good.
Original comment by si...@atanasyan.com
on 29 Apr 2013 at 1:42
Original issue reported on code.google.com by
ras46....@gmail.com
on 25 Apr 2013 at 7:08