Hi Scott, I can't reproduce your problem in a small program. Can you give your source code that's failing? Gaurav On 6/13/05, Weber, Scott <Scott.Weber@xxxxxxxxxxxxx> wrote: > Thanks for the tip. I am not using RTLD_GLOBAL. And it appears > there is no real definition for RTLD_LOCAL (i.e. 0x0000) > > Forgot to mention, I can make B.so declaration 'static short value' > and solve the problem. But that's not the fix I want. > But I'm concerned about the main execuable being corrupted by > the shared libs, which are to be created by anybody. > > I want to secure the main executable, not tell dozens of people > they have to code the sared module a specific way, and have to > keep up with all the vendors everytime there is a problem. > > Who gets the 'fvisibility' flag? And does it apply if I'm not > using the RTLD_GLOBAL flag? > > -----Original Message----- > From: Keith, Robert (London) [mailto:robert_keith@xxxxxx] > Sent: Monday, June 13, 2005 11:26 AM > To: Weber, Scott; gcc-help@xxxxxxxxxxx > Subject: RE: Globals visible in shared object libraries > > > I have had a similar problem with functions. After much searching the > result is as follows > > 1. Don't Load the module with RTLD_GLOBAL, which is what it sounds like > you are doing. If you absolutely have to do this then depending on the > version of the compiler that you are using I would recommend compiling > the code with the -fvisibility=hidden and making sure you only call > functions that you have extern'ed when calling across shared library > boundaries. This switch makes all symbols part of the local (dll/so) > namespace when its loaded and only pushes symbols you have explicitly > declared as global in to the global namespace. > > 2.Another alternative is to put the following in front of your > declaration for 'value' > > __attribute__ ((visibility("hidden"))) > > This will only be honoured if your compiler has had this functionality > included (or back ported). Basically this tells the compiler to look in > the local namespace then the global namespace when attempting to resolve > symbols using shared libraries. I honestly don't know what version this > was officially included in the compiler (I think it was 3.4, since it > has been back ported to many compilers even 3.2.3) > > So that's the quick fix - more information can be found at: > > http://gcc.gnu.org/wiki/Visibility > > And > > http://www.google.co.uk/url?sa=U&start=1&q=http://people.redhat.com/drep > per/dsohowto.pdf&e=10431 > > 3. Namespace the variable in each so and make sure that the functions > that update it reference it via the correct name space. > > E.g. namespace a { > value ; > } > void someFunc() { > a::value = 10 ; > } > > namespace b { > value ; > } > > Void someOtherFunc() { > b::value = 21 ; > } > > Regards, > > Robert Keith > > > -----Original Message----- > From: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On > Behalf Of Weber, Scott > Sent: 13 June 2005 17:13 > To: gcc-help@xxxxxxxxxxx > Subject: Globals visible in shared object libraries > > > > I have been digging at this for days, Now I'm turning to the experts. > > Given: > executable module A has a global variable (long) called 'value' It > loads module B.so using dlopen() and loads a function pointer (called > 'test') . > > Module B.so also has a global variable (some other type) called 'value' > > When I call test() in B.so and that function changes the contents of > 'value', it > changes to one in the A executable. Not the one in in B.so. (or I > assume they have been 'linked' into the same memory location) > > How can I DISABLE the dynamic linker from doing what appears to be > binding the variable 'value' in the two modules together? It's this a > HUGH hole where any shared library can get access to (and corrupt) > variables in the main executable? > > Everything think I've seen written seems to be regarding doing the > opposite. > > Any help is appreciated. > > -Scott Weber > (sorry if this is not exclusively plain text - Outlook... :-( ) > -------------------------------------------------------- > > If you are not an intended recipient of this e-mail, please notify the > sender, delete it and do not read, act upon, print, disclose, copy, > retain or redistribute it. Click here for important additional terms > relating to this e-mail. http://www.ml.com/email_terms/ > -------------------------------------------------------- >
