serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: [serf-dev] [serf] r2489 committed - In preparation of serf 1.4.0, remove the get_remaining function from t...
Date Sat, 12 Sep 2015 18:14:06 GMT


> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
> Sent: zaterdag 12 september 2015 18:30
> To: Greg Stein <gstein@gmail.com>
> Cc: dev@serf.apache.org
> Subject: Re: [serf-dev] [serf] r2489 committed - In preparation of serf 1.4.0,
> remove the get_remaining function from t...
> 
> On 12 September 2015 at 19:08, Greg Stein <gstein@gmail.com> wrote:
> >
> > On Sep 12, 2015 11:01 AM, "Ivan Zhakov" <ivan@visualsvn.com> wrote:
> >>
> >> On 12 September 2015 at 15:08, Greg Stein <gstein@gmail.com> wrote:
> >> > [redirected to dev@serf]
> >> >
> >> > On Mon, Apr 6, 2015 at 8:32 AM, Bert Huijben <bert@qqmail.nl> wrote:
> >> >
> >> >> > -----Original Message-----
> >> >> > From: serf-dev@googlegroups.com [mailto:serf-
> dev@googlegroups.com] On
> >> >> > Behalf Of serf@googlecode.com
> >> >> > Sent: maandag 6 april 2015 11:25
> >> >> > To: serf-dev@googlegroups.com
> >> >> > Subject: [serf-dev] [serf] r2489 committed - In preparation of
serf
> >> >> 1.4.0,
> >> >> > remove the get_remaining function from t...
> >> >> >
> >> >> > Revision: 2489
> >> >> > Author:   lieven.govaerts
> >> >> > Date:     Mon Apr  6 09:24:18 2015 UTC
> >> >> > Log:      In preparation of serf 1.4.0, remove the get_remaining
> >> >> > function
> >> >> > from the
> >> >> > bucket API.
> >> >> >
> >> >> > This reverts most of r2008, r2009, r2010 and r2198. From r2008
I kept
> >> >> > the
> >> >> > read_bucket_v2 function, which is needed for set_config.
> >> >>
> >> >> If we still keep the read_bucket_v2 feature, what is the reason for
> >> >> just
> >> >> removing get_remaining?
> >> >>
> >> >>
> >> >> We still have to handle the linkage problems if we use the
> >> >> read_bucket_v2() system for versioning, but we leave out the tests
that
> >> >> were added to find problems caused by different function pointers.
> >> >>
> >> >>
> >> >> The reason we see errors on this feature on several platforms is just
> >> >> this
> >> >> linkage problem, while the get_remaining code itself is pretty stable
> >> >> as
> >> >> far as I can tell. I'm guessing that the reason for removing the code
> >> >> is
> >> >> that we see this errors.
> >> >>
> >> >>
> >> >> Our scons scripts make us link both the static library and shared
> >> >> library
> >> >> versions of the same functions, and then a simple pointer comparison
on
> >> >> a
> >> >> function pointer isn't going to work as expected.
> >> >>
> >> >>
> >> >> And with a shared library build, there are other possible problems:
> >> >> sometimes you get a pointer to a wrapping function... or the pointer
> >> >> value
> >> >> is not guaranteed because the code might be moved under some
> >> >> circumstances
> >> >> (unload+load of library)
> >> >>
> >> >
> >> > So you're saying that a pointer to a specific function might have *two*
> >> > values under Windows? Within a single executable? That A could see a
> >> > different value from B?
> >> >
> >> This is not Windows specific problem, the original problem report was on
> >> Linux:
> >> "Buckets v2 check doesn't work on Linux in the test suite
> >> (test_aggregate_buckets fails)" [1]
> >>
> >> Bert commented  that serf on Windows had similiar problems, but I
> >> don't know details.
> >> [1] https://issues.apache.org/jira/browse/SERF-134
> >
> > That JIRA indicates there are multiple copies of the function, which is
> > clearly wrong.
> I don't know details, but it seems related how linker, loader and
> relocation works on Linux:
> http://reverseengineering.stackexchange.com/questions/1992/what-is-plt-got

I just experimented a bit with dll function exports with Microsoft compilers.

If I use the pattern we commonly use: .def file for exports and then using the .lib file and
normal function definitions in .h files the function pointers are *not* equal.

But if you annotate the functions with __declspec(dllimport) on the import side then the function
pointers *are* equal.

For the export side it does not matter if you use .def or __declspec(dllexport).

An import without an annotation uses the stub

I think http://stackoverflow.com/questions/22766540/semantics-of-imp-symbols provides more
info.



Note that using whole program optimization ("link time code generation") looks through these
stubs and returns the actual function pointers in all cases.


Summarizing:
* With our current code we can't trust pointer equality when using a DLL build on Windows
* Marking (all?) interesting functions with __declspec(dllimport) will fix the problem
(* Users can avoid the problem via LTCG in release mode.)


Using LTCG even made 4 different functions with just the same printf() call inside all have
the same address!

	Bert


Mime
View raw message