* Possible Relocation Overflow ?? @ 1999-07-13 7:48 Koundinya.K 1999-07-13 8:10 ` Mark Mitchell 1999-07-13 8:58 ` Ian Lance Taylor 0 siblings, 2 replies; 4+ messages in thread From: Koundinya.K @ 1999-07-13 7:48 UTC (permalink / raw) To: binutils; +Cc: ian Hi, At last I could compile the latest binutils (binutils-990713) !. But then when I try to compile hello.c I get the following error. ___________ Clip of gcc -v hello.c -o hello _____________________________ ****** Earlier stuff not shown ************** /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crt1.o: In function `__start': /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crt1.o(.text+0x14): relocation truncated to fit: R_MIPS_LO16 _gp_disp collect2: ld returned 1 exit status _____________________________________________________________________________ __ O.K Then I tried to use the startup files which my native compiler uses, and still got the same results. I used the binutils binaries which I had saved, and were from the previous version (binutils-990702). I did not have any problems that I am having from the current snapshot. Then out of curiosity I tried to generate a statically linked binary. ( Though I know that I have not been successful in generating one so far ), I got the error that _________________ Clip of gcc -static hello.c -o hello.static __________ **** Earlier stuff not shown *********** /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crti.o: In function `_init': /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crti.o(.init+0xc): undefined reference to `_gp_disp' collect2: ld returned 1 exit status ____________________________________________________________________________ And yet again I got the same result when I used the startup files which my native compiler uses. Are anyone else facing these type of problems ?? Cheers !!. Koundinya ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible Relocation Overflow ?? 1999-07-13 7:48 Possible Relocation Overflow ?? Koundinya.K @ 1999-07-13 8:10 ` Mark Mitchell 1999-07-13 8:58 ` Ian Lance Taylor 1 sibling, 0 replies; 4+ messages in thread From: Mark Mitchell @ 1999-07-13 8:10 UTC (permalink / raw) To: kk; +Cc: binutils, ian Well, on IRIX6, there is no problem with simple hello, world programs. But, apparently, something has been broken somewhere else. Please tell me: o Exactly how you configured binutils. o Exactly how `ld' is being invoked (you can get this from gcc -v). o Tar up all files and libraries being linked, and send the file to file to me as a mime-attachment. I'm sure I'll be able to fix the problem, with that information. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible Relocation Overflow ?? 1999-07-13 7:48 Possible Relocation Overflow ?? Koundinya.K 1999-07-13 8:10 ` Mark Mitchell @ 1999-07-13 8:58 ` Ian Lance Taylor 1999-07-13 15:28 ` Mark Mitchell 1 sibling, 1 reply; 4+ messages in thread From: Ian Lance Taylor @ 1999-07-13 8:58 UTC (permalink / raw) To: kk, Mark Mitchell; +Cc: binutils Date: Tue, 13 Jul 1999 20:25:03 +0530 From: "Koundinya.K" <kk@ddeorg.soft.net> /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crt1.o: In function `__start': /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crt1.o(.text+0x14): relocation truncated to fit: R_MIPS_LO16 _gp_disp Mark, your code does overflow checking on R_MIPS_LO16 applied to _gp_disp. That is what the ABI recommends, but I don't see how it can possibly work. Code routinely uses R_MIPS_HI16 and R_MIPS_LO16 to determine _gp_disp. It's OK if the R_MIPS_LO16 overflows, because the R_MIPS_HI16 is there to take care of it. /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crti.o: In function `_init': /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crti.o(.init+0xc): undefined reference to `_gp_disp' Mark, if you look back at the original code, you will see that the test for _gp_disp is done as the start of a series of if conditions. Testing for an undefined symbol is only done if the symbol is not _gp_disp. You need to replicate that, or you need to explicitly define _gp_disp somewhere; the symbol _gp_disp is supposed to be implicitly defined by the linker. I think we need to go back to the original code and make sure that every action it takes is reflected in the new code. I don't think writing the new code from first principles is a good idea. There is too much accumulated information which needs to be replicated. Ian ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible Relocation Overflow ?? 1999-07-13 8:58 ` Ian Lance Taylor @ 1999-07-13 15:28 ` Mark Mitchell 0 siblings, 0 replies; 4+ messages in thread From: Mark Mitchell @ 1999-07-13 15:28 UTC (permalink / raw) To: ian; +Cc: kk, binutils >>>>> "Ian" == Ian Lance Taylor <ian@zembu.com> writes: Ian> Date: Tue, 13 Jul 1999 20:25:03 +0530 From: "Koundinya.K" Ian> <kk@ddeorg.soft.net> Ian> /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crt1.o: In function Ian> `__start': Ian> /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crt1.o(.text+0x14): Ian> relocation truncated to fit: R_MIPS_LO16 _gp_disp Ian> Mark, your code does overflow checking on R_MIPS_LO16 applied Ian> to _gp_disp. That is what the ABI recommends, but I don't Ian> see how it can possibly work. Code routinely uses Ian> R_MIPS_HI16 and R_MIPS_LO16 to determine _gp_disp. It's OK Ian> if the R_MIPS_LO16 overflows, because the R_MIPS_HI16 is Ian> there to take care of it. Ian> /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crti.o: In function Ian> `_init': Ian> /usr/cygnus/H-mips-dde-sysv4.2MP/lib/crti.o(.init+0xc): Ian> undefined reference to `_gp_disp' Ian> Mark, if you look back at the original code, you will see Ian> that the test for _gp_disp is done as the start of a series Ian> of if conditions. Testing for an undefined symbol is only Ian> done if the symbol is not _gp_disp. I have attempted to restore the previous behavior with the following patch, which I checked in. (Of course, this still leaves the R_MIPS16* issues to resolve.) Also, since I didn't ever get a test-case, I didn't have a way of making sure that this fixed the problem. Ian, I would appreciate your inspection. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com 1999-07-13 Mark Mitchell <mark@codesourcery.com> * elf32-mips.c (mips_elf_calculate_relocation): Do not complain when _gp_disp is undefined. Do not check R_MIPS_LO16 for overflow when the relocation is against _gp_disp. Index: elf32-mips.c =================================================================== RCS file: /cvs/binutils/binutils/bfd/elf32-mips.c,v retrieving revision 1.19 diff -u -p -r1.19 elf32-mips.c --- elf32-mips.c 1999/07/12 17:15:34 1.19 +++ elf32-mips.c 1999/07/13 22:20:24 @@ -5770,11 +5770,13 @@ mips_elf_calculate_relocation (abfd, gp_disp_p = true; } - - /* If this symbol is defined, calculate its address. */ - if ((h->root.root.type == bfd_link_hash_defined - || h->root.root.type == bfd_link_hash_defweak) - && h->root.root.u.def.section) + /* If this symbol is defined, calculate its address. Note that + _gp_disp is a magic symbol, always implicitly defined by the + linker, so it's inappropriate to check to see whether or not + its defined. */ + else if ((h->root.root.type == bfd_link_hash_defined + || h->root.root.type == bfd_link_hash_defweak) + && h->root.root.u.def.section) { sec = h->root.root.u.def.section; if (sec->output_section) @@ -5908,7 +5910,22 @@ mips_elf_calculate_relocation (abfd, else { value = addend + gp - p + 4; - overflowed_p = mips_elf_overflow_p (value, 16); + /* The MIPS ABI requires checking the R_MIPS_LO16 relocation + for overflow. But, on, say, Irix 5, relocations against + _gp_disp are normally generated from the .cpload + pseudo-op. It generates code that normally looks like + this: + + lui $gp,%hi(_gp_disp) + addiu $gp,$gp,%lo(_gp_disp) + addu $gp,$gp,$t9 + + Here $t9 holds the address of the function being called, + as required by the MIPS ELF ABI. The R_MIPS_LO16 + relocation can easily overlfow in this situation, but the + R_MIPS_HI16 relocation will handle the overflow. + Therefore, we consider this a bug in the MIPS ABI, and do + not check for overflow here. */ } break; ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-07-13 15:28 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-07-13 7:48 Possible Relocation Overflow ?? Koundinya.K 1999-07-13 8:10 ` Mark Mitchell 1999-07-13 8:58 ` Ian Lance Taylor 1999-07-13 15:28 ` Mark Mitchell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).