open() return value

Qais Yousef Qais.Yousef at imgtec.com
Wed Jul 18 14:22:18 UTC 2012


> -----Original Message-----
> From: Qais Yousef
> Sent: 18 July 2012 10:20
> To: 'Bernhard Reutner-Fischer'
> Subject: RE: open() return value
> 
> > As said, a small, self-contained testcase that exhibits the bug would
> > help, please follow-up on the mailing-list with something we can try to
> reproduce..
> >
> > I'm curious which port that is? :)
> >
> > TIA && cheers,
> The attached c file fails for me. The first 2 open() return -1 and errno is 2, the 2nd
> set of open() after pthread is created return -2 and errno is 2. I think the errno
> stays 2 because it remembered it rather than being set correctly. When I use
> linuxthreads return value is always -1 (in the couple of test cases I have at least).
> 
> I am not terminating the thread correctly because I was just lazy to code it :p.
> Shouldn't make a difference except for better code quality. Please let me know if
> you could reproduce the problem.
> 
> The port is for Meta processor :)
> 
> Thanks,
> Qais

OK, I might understand what's going on but not really how. I managed to get it working by a combination of hacks:
	a) in fctnl.h make sure we use the definition of open() in '#ifdef __REDIRECT' block
	b) remove all reference to open.S in NPTL  sysdeps/unix/*/Makefile.commonarch
	c) set __libc_open and open as strong alisases to open64 in libc/*/open64.c
	e) recompile my test case (because of the change in the header file)

I might be able to minimise this, but I found this combination to work. NPTL seems to pull another definition of __libc_open() which is not right. Looking at the disassembly of libc.so I have no reference to __libc_open after my above modifications and all reference use open64. Before the modifications part of the code uses open64 and other uses __libc_open which causes the wrong behaviour. NPTL pulls the definition of this function somehow - I think, it's all magic to me still. Is it a compiler bug? Or a build system bug? Or something else? Hmmmmm

How should _FILE_OFFSET_BITS be set? I was surprised that I had to do the modification in (a).

Qais
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: open_test.c
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20120718/41d83f4c/attachment.c>


More information about the uClibc mailing list