X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=default; b=H9Mi4FDTiZSU49/BqpziwTl3wgiLrQ4v7wD25/L+whl hws+NstEsb3j9ZCTYv2zOI095oEw9c7Laehz7Q0jDvVEaX44suVUO9VBdjqMqRlx MCbgREgUXUzQWsk0reoBVZqCAsgL7oFToTHwX+dFK2OvWPOSyD9K/sQnvcNyTtx0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; s=default; bh=g/+QDgTwJBvT6vrBn2YGA1gZ+7Y=; b=nSPGl+LHv1B2mFdkE 2tDmPaH4jEx4lUR5Yv24MfRs/cLNhO5Di6BwZ798CU3YWbH2X/NznDKHoTB7TGRn wXVBfWSDrphrZHrHAYNaQbRCgFXHSV2UKXXuOF2S/C5bF2GYOPaxA4Z6XThsRxc9 mV7I+XDYQ9jFngikVB5vZGAd3M= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: <cygwin.cygwin.com> List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com> List-Archive: <http://sourceware.org/ml/cygwin/> List-Post: <mailto:cygwin AT cygwin DOT com> List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail.lysator.liu.se Message-ID: <542273F3.3000504@lysator.liu.se> Date: Wed, 24 Sep 2014 09:34:11 +0200 From: Peter Rosin <peda AT lysator DOT liu DOT se> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: problem with dlsym to fetch address of some functions References: <CAHAq8pFUmaSaiRc4LiLK+ieAqB_sPF8iaHFZQ=fzoM-3d+V5PQ AT mail DOT gmail DOT com> <5421CCA1 DOT 6000502 AT gmail DOT com> <CAHAq8pEWtSZ8F7bF=4-r2YSQmYnnYL0tcFuMp7gOW-va2g4=mg AT mail DOT gmail DOT com> In-Reply-To: <CAHAq8pEWtSZ8F7bF=4-r2YSQmYnnYL0tcFuMp7gOW-va2g4=mg@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2014-09-23 21:52, Paulo César Pereira de Andrade wrote: > 2014-09-23 16:40 GMT-03:00 Marco Atzeri <marco DOT atzeri AT gmail DOT com>: >> On 23/09/2014 20:43, Paulo César Pereira de Andrade wrote: >>> >>> Hi, >>> >>> Forgive me if this is expected. I am probably abusing dlsym >>> behavior on other systems. >> >> >> It will be much more clear if you > > Sorry for not clear initial problem description. > >> 1) produce a simple small complete test case, > > $ cat x.c > extern int sprintf(char*,char*, ...); > extern int puts(char*); > extern void *dlsym(void*, char*); > char buff[128]; > int main(void) { > int (*fn)(char*,char*,...); > sprintf(buff, "%.1f", 1.0); > puts(buff); > fn = dlsym((void*)0, "sprintf"); > (*fn)(buff, "%.1f", 1.0); > puts(buff); > return 0; > } > > $ gcc -O0 -g3 x.c > >> 2) explain the outcome you obtain (or not) > > $ ./a.exe > 1.0 > f The problem is that sprintf is a popular function available in many dlls. Especially so on Cygwin which is a layer upon layer thingy. When you are not specifying what dll dlsym should look in, dlsym just picks the first sprintf it finds. Consider this program: #include <stdio.h> #include <dlfcn.h> char buff[128]; int main(void) { int (*fn)(char*,char*,...); void *cygwin1 = dlopen("cygwin1.dll", RTLD_GLOBAL); void *ntdll = dlopen("ntdll.dll", RTLD_GLOBAL); void *msvcrt = dlopen("msvcrt.dll", RTLD_GLOBAL); printf("cygwin1 %p\n", cygwin1); printf("ntdll %p\n", ntdll); printf("msvcrt %p\n", msvcrt); fn = dlsym(RTLD_DEFAULT, "sprintf"); printf("\n\"default\" sprintf %p\n", fn); (*fn)(buff, "%.1f", 1.0); puts(buff); fn = dlsym(cygwin1, "sprintf"); printf("\ncygwin1 sprintf %p\n", fn); (*fn)(buff, "%.1f", 1.0); puts(buff); fn = dlsym(ntdll, "sprintf"); printf("\nntdll sprintf %p\n", fn); (*fn)(buff, "%.1f", 1.0); puts(buff); fn = dlsym(msvcrt, "sprintf"); printf("\nmsvcrt sprintf %p\n", fn); (*fn)(buff, "%.1f", 1.0); puts(buff); return 0; } It produces the following output for me (Cygwin/32): cygwin1 0x61000000 ntdll 0x77970000 msvcrt 0x75c70000 "default" sprintf 0x77a45555 f cygwin1 sprintf 0x610d7784 1.0 ntdll sprintf 0x77a45555 f msvcrt sprintf 0x75c8d354 1.0 So, it appears that you get ntdll:sprintf, which apparently is not a very complete version. Maybe Cygwin could do better and look in Cygwin dlls before going on to lower level stuff? PTC, I'm sure... Cheers, Peter -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple