Messages in this thread | | | From | "Linda Walsh" <> | Subject | RE: syscall defines deficiency or gcc bug? | Date | Wed, 2 Aug 2000 15:35:41 -0700 |
| |
Ouch. So lemme think...is it possible for some code macro to detect it's being compiled pic on the x86 and use alternate macros that save the appropriate registers?
The reason I ask is that other wise we are likely going to have to come up with custom syscall macros for each platform -- now those macros may be exactly the same as the original on other platforms (they may not have this problem), but it's alot of icky wasted code space.
In this case, we *are* the library, so my fear is writing pic code that works on x86 but doesn't on another. It'd be nice not to come up with a different mechanism if this isn't broken in the same way on the other platforms, but to instead fix the x86 platform.
In this situation, we are the library writer, so what we want to stay away from is having to write platform specific code in the library.
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
> -----Original Message----- > From: Brian Gerst [mailto:bgerst@didntduck.org] > Sent: Wednesday, August 02, 2000 3:13 PM > To: Linda Walsh > Cc: linux-kernel@vger.rutgers.edu > Subject: Re: syscall defines deficiency or gcc bug? > > > Linda Walsh wrote: > > > > I have some code that includes asm-i386/unistd.h and has defines for > > the functions I want to call (audit related) > > > > Thing is, that I want to also be able to call those functions in > > a shared library compiled with -fpic (or -fPIC). When I use the > > fpic option to gcc, I get: > > > > asm-audit.h: In function `aud_setluid': > > asm-audit.h:17: Invalid `asm' statement: > > asm-audit.h:17: fixed or forbidden register 3 (bx) was spilled for class BREG. > > > > That line contains: > > _syscall1(int, aud_setluid, uid_t, luid) > > > > Basically and syscall definition I use that has input arguments gets > > the above error message. Functions with no arguments generate no > > error. > > > > The problem appears to lie in gcc's global register allocator. 'greg'. > > So what I'm wondering is "does this point to a bug in gcc"? or is there > > some different way the syscalls could be defined to make them portable > > between both cases? > > PIC code on the x86 reserves the %ebx register for an offset pointer, > but the syscall interface defines %ebx as the first argument of a > syscall. Glibc works around this by pushing and popping %ebx around the > syscall. You would need something like this: > > #define _syscall1(type,name,type1,arg1) \ > type name(type1 arg1) \ > { \ > long __res; \ > __asm__ volatile ("pushl %%ebx; movl %2, %%ebx; int $0x80; popl %%ebx" \ > : "=a" (__res) \ > : "0" (__NR_##name),"g" ((long)(arg1))); \ > __syscall_return(type,__res); \ > } > > -- > > Brian Gerst >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |