Information regarding -fPIC support for Interix gcc
Hi I am currently looking at interix gcc and found that -fPIC generated binaries crash although not all binaries crash. This has been known for quite some time since I found a lot of posts about it. I want to know if this issue has already been fixed and a patch submitted or this issues is still pending on Interix gcc. I am currently investigating this issue and was wondering if somebody has fixed it or not before starting investigation. Thanks Mayank
RE: Information regarding -fPIC support for Interix gcc
I work for Microsoft SFU(services for unix) group and I am currently investigating this fPIC issue for gcc 3.3 which is available with sfu 3.5. I have currently no intention of supporting the latest gcc for interix but I am more interested in fixing this fPIC issue for Interix as well as contributing this fix to gcc users on Interix. Has anybody before looked at this issue or is aware of it ? Thanks Mayank -Original Message- From: Joe Buck [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 10:20 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Information regarding -fPIC support for Interix gcc On Thu, Mar 22, 2007 at 04:22:37PM +0800, Mayank Kumar wrote: > I am currently looking at interix gcc and found that -fPIC generated > binaries crash although not all binaries crash. This has been known for > quite some time since I found a lot of posts about it. I want to know if > this issue has already been fixed and a patch submitted or this issues > is still pending on Interix gcc. I am currently investigating this > issue and was wondering if somebody has fixed it or not before starting > investigation. I took a look at Bugzilla, and the first thing I see is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212 which indicates that the compiler hasn't even bootstrapped on Interix in a long time, though workarounds are proposed and a patch is given against a 4.2 snapshot. It looks like no one has treated the platform as a priority. It's just a matter of not having a sufficiently motivated volunteer, or else the sufficiently motivated volunteers are not contributing their patches to gcc.gnu.org. So, where are you getting your Interix gcc? Are you using an FSF release, or is someone trying to support a fork?
RE: Information regarding -fPIC support for Interix gcc
Ok, since I didn't get any pointers in this area. I have a more generic question now to everybody:- I am new to gcc development as well as its architecture. I am looking forward to fix the -fPIC issue for Interix. As of now I found that a shared library compiled with fPIC crashes due to some wrong assembly instructions(a jmp instruction) embedded into a function call which cause it to jump unconditionally to a different function altogether whereas the c code has no such jumps or function calls. Can some body point me to the part of source code that I should look into for this. I mean:- 1: the part which is responsible for generating this code from c code. 2: the part of the gcc code where -fPIC is being handled. 3: any other pointers to investigating this would be helpful. Thanks Mayank -Original Message- From: Paul Brook [mailto:[EMAIL PROTECTED] Sent: Friday, March 23, 2007 2:24 AM To: gcc@gcc.gnu.org Cc: Mayank Kumar Subject: Re: Information regarding -fPIC support for Interix gcc On Thursday 22 March 2007 20:20, Mayank Kumar wrote: > I work for Microsoft SFU(services for unix) group and I am currently > investigating this fPIC issue for gcc 3.3 which is available with sfu 3.5. gcc3.3 is really quite old, and hasn't been maintained for quite some time. You're unlikely to get a particularly useful response from this list (or any volunteer gcc developers) unless you're working with current gcc. Of course there are organisations who will provide you with commercial support for older gcc releases. That's a separate issue though. Paul
Does anybody know of testuites/testcases for shared library, dynamic loader, etc
I am looking for testcases for testing the following on interix:- 1: shared library support 2: dynamic loader ld.so working Are then any comprehensive testsuites available for the same ? Thanks Mayank
Where is ld.so and libdl.so built from
In gcc packages, I could not find ld.so and libdl.so Binutils only contains ld. Where can I find the gnu source code for libdl.so and ld.so Thanks Mayank
RE: Where is ld.so and libdl.so built from
Thanks for this information. I wanted to take a look at the code. Yes MS has its own shared library loader and libc. Thanks Mayank -Original Message- From: Andrew Pinski [mailto:[EMAIL PROTECTED] Sent: Monday, March 26, 2007 9:36 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Where is ld.so and libdl.so built from On 3/26/07, Mayank Kumar <[EMAIL PROTECTED]> wrote: > In gcc packages, I could not find ld.so and libdl.so > Binutils only contains ld. > > Where can I find the gnu source code for libdl.so and ld.so They come from glibc which I doubt MS uses as they have their own shared library (dll) loader and libc. -- pinski
RE: Information regarding -fPIC support for Interix gcc
Further to this email, I did some more investigation, here is some more detailed information about what I am doing:- 1: Compiled a shared library(tcl8.4.14) using -fPIC on gcc4.3.0 for interix(was able to compile gcc 4.3.0 for interix) 2: The assembly generated for a particular region of code which causes a jmp to an invalid location, obtained using gcc -S -fPIC is as follows:- movl-20(%ebp), %eax sall$2, %eax movl[EMAIL PROTECTED](%ebx,%eax), %eax addl%ebx, %eax jmp *%eax .section.rdata,"r" .balign 4 L32: .long [EMAIL PROTECTED] 3:the assembly generated while executing the binary linked with the shared library 0x100889dc : mov0xffec(%ebp),%eax 0x100889df : shl$0x2,%eax 0x100889e2 : mov 0xbd14(%eax,%ebx,1),%eax 0x100889e9 : add%ebx,%eax 0x100889eb : jmp*%eax 4:Similar code compiled and run on a FreeBsd box using gcc shared library and fPIC produces the following assembly:- 0x2810a1a8 : mov0xffec(%ebp),%eax 0x2810a1ab : shl$0x2,%eax 0x2810a1ae : mov 0x4f14(%eax,%ebx,1),%eax 0x2810a1b5 : add%ebx,%eax 0x2810a1b7 : jmp*%eax 5:So corresponding to ---movl[EMAIL PROTECTED](%ebx,%eax), %eax, The assembly generated on interix is --- mov0xbd14(%eax,%ebx,1),%eax Whereas on bsd box, it is --- mov0x4f14(%eax,%ebx,1),%eax Here the offset bd14 in case of interix is wrong which is causing the jmp *eax to jump to a different function. Now my questions are:- 1: What does [EMAIL PROTECTED] mean ? Is it at offset L32 in GOTOFF table ? 2: Shld the value of [EMAIL PROTECTED] remain same for all machines for which the same library/binary is compiled? 3: Does the above mean that the GLOBAL_OFFSET_TABLE is not being populated correctly ? If that is so, why would this be interix specific? 4: I can see these offset's with objdump -D also, so I concluded that this could not be a linker or loader issue but a compiler issue only. Which part of gcc code should I refer for this issue? 5:Lastly, should I raise a bug in gcc Bugzilla to track this and assign it to myself or what is the procedure to track this ? Any other help or pointers in this regard shld be useful in investigating further. NOTE: I could repro this issue with gcc4.3.0 compiler and linker/loader/assembler same as the one that ships with Interix. Thanks Mayank -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: Friday, March 23, 2007 9:36 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Information regarding -fPIC support for Interix gcc Mayank Kumar <[EMAIL PROTECTED]> writes: > Ok, since I didn't get any pointers in this area. > I have a more generic question now to everybody:- > > I am new to gcc development as well as its architecture. I am looking > forward to fix the -fPIC issue for Interix. As of now I found that a shared > library compiled with fPIC crashes due to some wrong assembly instructions(a > jmp instruction) embedded into a function call which cause it to jump > unconditionally to a different function altogether whereas the c code has no > such jumps or function calls. > Can some body point me to the part of source code that I should look into for > this. I mean:- These are all rather difficult questions to answer succintly. gcc is a large code base. It is not organized in a way which makes it simple to answer this sort of question. > 1: the part which is responsible for generating this code from c code. If by "this code" you mean inserting a jmp instruction, there are many possibilities. The first one you should look at is that at least on some x86 platforms gcc intentionally calls __i686.get_pc_thunk.bx as part of setting the PIC register. This looks a different function but it is just a tiny helper routine. > 2: the part of the gcc code where -fPIC is being handled. It is handled in a number of places. Search for flag_pic. For i386 in particular the most exciting place is probably legitimize_pic_address. > 3: any other pointers to investigating this would be helpful. Reading the gcc internal's manual? Ian
RE: Information regarding -fPIC support for Interix gcc
Hi Murali/Everybody 1: I am keen on understanding how does the offset of L32 from _GLOBAL_OFFSET_TABLE_ generated ? I mean if assembly is Movl [EMAIL PROTECTED](%ebx,%eax),%eax then how does is gets converted to mov 0xbd14(%eax,%ebx,1),%eax. I guessed that L32 is at start of .rodata section which is the only section of its type. So in my opinion it should have been Address of .got section - address of .rodata section. But I am not getting the generated offset seen in objdump as the same as I calculate from the above method on a FreeBSD box. Can anyone help here ? On interix, the offset is being calculated as .got - .rodata only, so is there anything wrong in this? I am assuming that this is the only thing that could be going wrong. 2: Murali, Interix generated pecoff binaries have _GLOBAL_OFFSET_TABLE_ defined. We also have .got section/.plt section etc which are present in a pic compiled code, hence your patch may fix the problem in an alternate way but may not be the correct fix for Interix. Yes , you are right that the generated assembly is for a switch case and is actually a jump table. 3: Also, after further investigation, I found that Interix compiled shared libraries with fPIC flag only cause a crash when there is a jump table being created for a switch case. I compiled the same shared library which was crashing with ---fPIC and -fno-jump-table on 4.3 and it worked great. So are there any jump table experts out there who could help me investigate what is going wrong in there? I have attached objdump -D output and gcc -S output for the shared library(repro code which is basically a small dummy library). --Ass contains objdump -D output --lib1.s contains gcc -S output Look at the jump table generated for switch case inside func1_1? This causes the crash because the control jumps to invalid location thru jmp*%eax. Thanks Mayank -Original Message- From: Murali Vemulapati [mailto:[EMAIL PROTECTED] Sent: Saturday, March 31, 2007 9:57 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Information regarding -fPIC support for Interix gcc On 3/31/07, Mayank Kumar <[EMAIL PROTECTED]> wrote: > Further to this email, I did some more investigation, here is some more > detailed information about what I am doing:- > > 1: Compiled a shared library(tcl8.4.14) using -fPIC on gcc4.3.0 for > interix(was able to compile gcc 4.3.0 for interix) > 2: The assembly generated for a particular region of code which causes a jmp > to an invalid location, obtained using gcc -S -fPIC is as follows:- > movl-20(%ebp), %eax > sall$2, %eax > movl[EMAIL PROTECTED](%ebx,%eax), %eax > addl%ebx, %eax > jmp *%eax > .section.rdata,"r" > .balign 4 > L32: > .long [EMAIL PROTECTED] > > 3:the assembly generated while executing the binary linked with the shared > library > 0x100889dc : mov0xffec(%ebp),%eax > 0x100889df : shl$0x2,%eax > 0x100889e2 : mov > 0xbd14(%eax,%ebx,1),%eax > 0x100889e9 : add%ebx,%eax > 0x100889eb : jmp*%eax > > 4:Similar code compiled and run on a FreeBsd box using gcc shared library and > fPIC produces the following assembly:- > 0x2810a1a8 : mov0xffec(%ebp),%eax > 0x2810a1ab : shl$0x2,%eax > 0x2810a1ae : mov > 0x4f14(%eax,%ebx,1),%eax > 0x2810a1b5 : add%ebx,%eax > 0x2810a1b7 : jmp*%eax > > 5:So corresponding to > ---movl[EMAIL PROTECTED](%ebx,%eax), %eax, > The assembly generated on interix is > --- mov0xbd14(%eax,%ebx,1),%eax > Whereas on bsd box, it is > --- mov0x4f14(%eax,%ebx,1),%eax > > Here the offset bd14 in case of interix is wrong which is causing the jmp > *eax to jump to a different function. > > Now my questions are:- > 1: What does [EMAIL PROTECTED] mean ? Is it at offset L32 in GOTOFF table ? It means the offset of L32 from the symbol GLOBAL_OFFSET_TABLE. It looks like this refers to a switch table. It is indexing into a jump table and jmping to that label. > 2: Shld the value of [EMAIL PROTECTED] remain same for all machines for which > the same library/binary is compiled? > 3: Does the above mean that the GLOBAL_OFFSET_TABLE is not being populated > correctly ? If that is so, why would this be interix specific? The Global Offset Table (GOT) is generated by the linker. But this is specific to Elf binaries. The PECOFF ABI does not define a GOT. Nor does it support the relocation types R_386_GOTOFF and R_386_GOT32. > 4: I can see these offset's with objdump -D also, so I concluded that this > could not be a linker or loader issue but a compiler issue only. Which part > of gcc code should I refer for this issue? > 5:Lastly, should I raise a bug
RE: Information regarding -fPIC support for Interix gcc
Hi Ian Thanks for replying. For Movl [EMAIL PROTECTED](%ebx,%eax),%eax > mov 0xbd14(%eax,%ebx,1),%eax I verified that data contained in .rdata section is all wrong in my case with both my gcc3.3 compiler as well gcc4.3 compiler. This is why the jump happens to the wrong code which lies outside the function. Can you point me to the relevant section of gcc code which populates the .rdata section or calculates these values to be populated in there ? Thanks in advance . Mayank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Lance Taylor Sent: Tuesday, April 03, 2007 12:28 AM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Information regarding -fPIC support for Interix gcc Mayank Kumar <[EMAIL PROTECTED]> writes: > 1: I am keen on understanding how does the offset of L32 from > _GLOBAL_OFFSET_TABLE_ generated ? I mean if assembly is > > Movl [EMAIL PROTECTED](%ebx,%eax),%eax then how does is gets converted to mov > 0xbd14(%eax,%ebx,1),%eax. I guessed that L32 is at start of .rodata > section which is the only section of its type. So in my opinion it should > have been > Address of .got section - address of .rodata section. But I am not getting > the generated offset seen in objdump as the same as I calculate from the > above method on a FreeBSD box. Can anyone help here ? On interix, the offset > is being calculated as .got - .rodata only, so is there anything wrong in > this? I am assuming that this is the only thing that could be going wrong. The calculation for the R_386_GOTOFF relocation is specified in the i386 ELF ABI Processor Supplement. It should be the value of the symbol L32 minus the start of the GOT. The start of the GOT is defined by the value of _GLOBAL_OFFSET_TABLE_, and need not be the start of the .got section. The idea is that R_386_GOTOFF gives a position independent offset. It is then added to the address of the global offset table to get the actual offset. > 3: Also, after further investigation, I found that Interix compiled shared > libraries with fPIC flag only cause a crash when there is a jump table being > created for a switch case. I compiled the same shared library which was > crashing with ---fPIC and -fno-jump-table on 4.3 and it worked great. So are > there any jump table experts out there who could help me investigate what is > going wrong in there? I have attached objdump -D output and gcc -S output for > the shared library(repro code which is basically a small dummy library). > --Ass contains objdump -D output > --lib1.s contains gcc -S output > Look at the jump table generated for switch case inside func1_1? This causes > the crash because the control jumps to invalid location thru jmp*%eax. Presumably the values in the table are wrong or the values computed by the relocations are wrong. Step through the code instruction by instruction to see what is happening. There are no secrets here. You have all the information required to figure this out. If you have specific questions we may be able to ansewr them, but it's difficult to answer general questions like why something doesn't work. Ian
RE: Information regarding -fPIC support for Interix gcc
Hi Ian/All That information was really very helpful. I have been able to localize the bug. The issue is in the assembler. When I create a object file using the assembler(as test.s -o test.o), the contents of .rdata which contains the jump table is all wrong. The assembly file:- .section.rdata,"r" .balign 4 L8: .long [EMAIL PROTECTED] .long [EMAIL PROTECTED] .long [EMAIL PROTECTED] .long [EMAIL PROTECTED] .long [EMAIL PROTECTED] .long [EMAIL PROTECTED] The object file generated by assembly(the contents of .rdata) Contents of section .rdata: 9900 3200 4700 5c00 2...G...\... 0010 7100 8600q... Values of symbol L2-L7 0099 t L2 0032 t L3 0047 t L4 005c t L5 0071 t L6 0086 t L7 Basically the assembly file shows, that the contents of .rdata are value of Labels relative to GOT but in the assembly phase since GOT is not defined, the contents of .rdata should have been all zeroes(as was the case for elf binaries on a bsd box) but for interix coff binaries, the contents are actually values of labels. When this objects gets further linked to become a shared library, the GOT gets defined and hence the value Label-GOT(I mean L2-GOT or L3-GOT or L4-GOT) gets added to the contents of .rdata hence giving wrong jump targets for switch case. I have fixed this temporarily in bfd_install_relocation but I know that this is not the place where the fix should be. Now I could not figure out how this case is handled in elf binaries and where in the code ? If somebody can point me to the code where and how elf takes care of the above scenario , I could make a similar fix for coff binaries. Thanks Mayank -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 9:14 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Information regarding -fPIC support for Interix gcc Mayank Kumar <[EMAIL PROTECTED]> writes: > For Movl [EMAIL PROTECTED](%ebx,%eax),%eax > mov > 0xbd14(%eax,%ebx,1),%eax > > I verified that data contained in .rdata section is all wrong in my case with > both my gcc3.3 compiler as well gcc4.3 compiler. > This is why the jump happens to the wrong code which lies outside the > function. > > Can you point me to the relevant section of gcc code which populates the > .rdata section or calculates these values to be populated in there ? gcc emits the code you see in the .s file. In this case it is just code like ".long [EMAIL PROTECTED]", which certainly looks right to me. It is the assembler which determines the value to place in the .o file; for the GNU binutils, this happens in gas/config/tc-i386.h; look for the handling of got_reloc. It is the linker which computes the final value in the executable; for the GNU binutils search for GOTOFF in bfd/elf32-i386.c. Ian
RE: gcc 4.3 on Interix
Hi Flavell I am sorry for replying so late. If you can detail me the exact scenario where program compiled using gcc3.3 crashes, then we can try to help you. Tell us about the following:- 1: machine spec 2: OS with SP if any 3: program u are trying to compile 4: what options u are passing to compiler. Regarding compiling on 4.1.2, I guess no active support is present for the same, but I could see some bugs filed in bugzilla for people being able to compile gcc on interix. I will try to dig that bug out. I am working on compiling 4.1.2 on SUA (Subsystem for Unix -based Applications) available with Win2k3 R2 and Windows Vista Ultimate/Enterprise SKU. Will let you know when this is done. HTH Thanks Mayank From: Flavell, Conwyn [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 08, 2007 1:21 AM To: Mayank Kumar; [EMAIL PROTECTED] Cc: gcc@gcc.gnu.org Subject: gcc 4.3 on Interix Hi Everybody Interix downloads with gcc 3.3 and normally works on all my PC W2000 and XP but I have a XP Dell Processor x86 Family 6 Model 14 Stepping 8 GenuineIntel ~1830 Mhz And gcc 3.3 has a segmentation fault in cc1 in the most basic of programs. So I thought I would try to build GCC 412 on my working XP machine. I downloaded I ran make configure which generated the makefile And then the instructions says make bootstrap but when I try it says do not nkow to make boot strap stop. I tried make and make all but they do nothing but make -dA does produce lots of output so it is running through the make file. Can you briefly tell me what I need to do to generate 412 under interix from a interix environment (running under XP) I use Internix to run a program that collects data from Cisco routers and generates web pages. Regards Conwyn * This email is intended solely for the use of the individual to whom it is addressed and may contain confidential and/or privileged material. Any views or opinions presented are solely those of the author and do not necessarily represent those of AGCO. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. Neither AGCO nor the sender accepts any responsibility for viruses and it is your responsibility to scan and virus check the e-mail and its attachment(s) (if any). * AGCO Limited, a limited company, registered in England (registered no.509133) with its registered office at Abbey Park Stoneleigh, Kenilworth CV8 2TQ, England.
Major Differences between gcc4.2 and gcc3.3
I want to know the major differences between gcc4.2 and gcc3.3. Can some one point to a document/page where I can find this information.
RE: Help required on use of gcc on SFU 3.5
Hi Naren >From the description that you just gave me, it looks like you aren't doing >anything special, just compiling a simple hello world program on SFU3.5. The only known issues wrt to this is that you might have DEP(Data Execution Protection) enabled which could be causing this. We have recently issued a QFE to one of our customers for this. So pls verify if you have that enabled, disable it and try once more. If that works for you, I will loop you with our support who will point you to the QFE which allows you to compile with DEP enabled. Thanks Mayank From: Naren Santanam (Information Technology) [mailto:[EMAIL PROTECTED] Sent: Friday, July 27, 2007 3:43 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Help required on use of gcc on SFU 3.5 Hi Mayank, I was reading through a lot of emails that were answered by you on the gnu forum for gcc. I have been trying to use the gcc to compile some c programs, but havent been able to. Well, here's my set up: Windows XP SP2 SFU 3.5 (with the default version of gcc installed). When i attempt to compile a simple "hello world " c program, here's the output : $ gcc.exe -v -da -Q abcd.c Reading specs from /opt/gcc.3.3/lib/gcc-lib/i586-pc-interix3/3.3/specs Configured with: : (reconfigured) : (reconfigured) /dev/fs/C/gnu2.intel/egcs.s ource//configure --verbose --prefix=/opt/gcc.3.3 --disable-shared --with-stabs - -enable-nls --with-local-prefix=/opt/gcc.3.3 --with-gnu-as --with-gnu-ld --enabl e-targets=i586-pc-interix3 --enable-threads=posix Thread model: posix gcc version 3.3 /opt/gcc.3.3/lib/gcc-lib/i586-pc-interix3/3.3/cc1 -v -D__GNUC__=3 -D__GNUC_MINO R__=3 -D__GNUC_PATCHLEVEL__=0 abcd.c -dumpbase abcd.c -da -auxbase abcd -version -o /tmp/cc5yiaKf.s gcc.exe: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. Would you be able to tell me if there are any settings that need to be changed or about any known issues on this ? Thanks, Naren. Disclaimer and confidentiality note The contents of this e-mail and any attachments relating to the official business of Capitec Bank Limited (Capitec) are proprietary to Capitec. It is confidential, legally privileged and protected by law. Capitec does not own and endorse any other content. Views and opinions are those of the sender unless clearly indicated as being that of Capitec. The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Capitec cannot assure that the integrity of this communication has been maintained or that it is free of errors, virus, interception or interference.
