Diego Nieto Cid, on Tue 08 Mar 2016 17:18:56 -0300, wrote:
> From the main function, the pthread implementation is called but
> from libdl the implementation provided by libc is used.
IIRC libdl uses its own separate mini-libc for its own use indeed.
Samuel
Hi
On Mon, Mar 07, 2016 at 08:45:59PM -0300, Diego Nieto Cid wrote:
>
> I'm not sure what's going on. I've made some simple tests trying
> to imitate the setup but weak symbols were correctly overriden.
>
Well, this is weird. I added a call to cthread_getspecific to the
test program, and now the
Hi
Here's another iteration of the patch. __libc_getspecific now
considers the case were pthread is not loaded except when the
containing file is being compiled for the loader.
The test case, when built without pthread, now works
approprietly:
diego@hird:~/src/test-cases/dlopen-error$ ./main
Diego Nieto Cid, on Sun 06 Mar 2016 21:11:58 -0300, wrote:
> The problem with the function as it is, is that by calling
> cthread_getspecific it forces dlerror to clobber errno; and then the console
> client is in trouble.
>
> May I do as below?
>
>void *val = NULL;
>if ( _cthread_init_
El 6 mar 2016, a las 20:07, Samuel Thibault escribió:
>
>__libc_getspecific is not a weak symbol,
>keep it as it is, calling
>cthread_getspecific.
Oh, yes that's right. I didn't notice the attribute came from a Debian patch
meant to be dropped.
The problem with the function as it is, is tha
Diego Nieto Cid, on Sun 06 Mar 2016 22:56:15 -0300, wrote:
> I had to add the first condition because otherwise a segmentation
> fault was triggered.
Ah, right. The rest of the code does that too. That's normal for an
undefined symbol.
> Finally, while this fixes the case where pthread is not p
Hi
The patch for thread-specific data key related functions is attached. As
discussed on IRC, the modifications were extended to __libc_setspecific
and __libc_getspecific.
It has been generated with quilt against debian source package.
On Sun, Feb 28, 2016 at 07:57:43PM +0100, Samuel Thibault wr
Diego Nieto Cid, on Sun 28 Feb 2016 16:53:51 -0300, wrote:
> On Sun, Feb 28, 2016 at 07:57:43PM +0100, Samuel Thibault wrote:
> >
> > Using watch in gdb :)
> >
> > I've added fprintf(stderr,"%p\n", &errno); to get the address of errno:
> >
>
> Oh, that's interesting. I've been struggling with "
Hi
On Sun, Feb 28, 2016 at 07:57:43PM +0100, Samuel Thibault wrote:
>
> Using watch in gdb :)
>
> I've added fprintf(stderr,"%p\n", &errno); to get the address of errno:
>
Oh, that's interesting. I've been struggling with "display errno",
or "display *__errno_location()" without success.
>
>
Hello,
Diego Nieto Cid, on Sun 28 Feb 2016 01:10:27 -0300, wrote:
> Any ideas?
Using watch in gdb :)
I've added fprintf(stderr,"%p\n", &errno); to get the address of errno:
(gdb) r
Starting program: /home/samy/main
[New Thread 28384.6]
Breakpoint 1, main (argc=1, argv=0x102bda4) at main.c:11
Hi
I found a strange behaviour in `dlerror` with regard
to errno. When the function is called, it returns the
correct error message but sets errno to ENOSYS.
Thus, future usages of errno don't reflect the real reason
why the previous call to `dlopen` failed.
A little test case for this quirk is
11 matches
Mail list logo
