- Putting a function in shared memory - 3 Updates
- Are bitfields useful? - 5 Updates
- TRACE produces nothing - 2 Updates
- XanaNews Statistic for comp.lang.c++. 8/1/2020 7:47:43 AM - 1 Update
| Frederick Gotham <cauldwell.thomas@gmail.com>: Aug 01 01:57PM -0700 So let's start off with a simple function: void cpystring(char *to, char const *from) { while ( *to++ = *from++ ); } Note that this function does not access a global variable, nor does it call any other functions. Everything it accesses is on the stack. So let's say I compile this function to 20 bytes of machine code. I then copy this machine code into memory that is shared between processes (for example on Linux: a shared memory object). MS-Windows has a similar interprocess memory feature. I then set the permissions on this interprocess memory to allow execution. I can then have any number of separate processes that do the following: char buf1[] = "dog"; char buf2[] = "cat"; void (*cpystring)(char *to, char const *from); int main(void) { void const *const mem = MapInterprocessMemory("gotham_cpystring"); cpystring = (void (*)(char*,char const *))mem; cpystring(buf1,buf2); } This will work, right? But if I make it a little more complicated, for example if I call a function from within cpystring like this: void cpystring(char *const to, char const *const from) { unsigned const len = strlen(from); for (unsigned i = 0; i <= len; ++i) to[i] = from[i]; } This won't work I don't think, because the hardcoded address of 'strlen' will be different for each process (...I think?). I think the way around this would be to pass the address of strlen as a stack parameter like this: void cpystring(char *const to, char const *const from, unsigned (*const lenstring)(char const*)) { unsigned const len = lenstring(from); for (unsigned i = 0; i <= len; ++i) to[i] = from[i]; } I think this should work. I can try this on a PC when I'm at home later. Is there anything else to consider when trying to execute a function from shared interprocess memory? What I'm trying to do here is to come up with a third way of dynamically loading a shared library and executing code from it. So far I have two methods: (1) When building, at the linking stage just specify -l:libmonkey.so (2) At runtime, call dlopen, LoadLibrary followed by dlsym, GetProcAddress (3) Copy executable code into a shared memory object, and then just get other processes to map the shared memory and call the function |
| Juha Nieminen <nospam@thanks.invalid>: Aug 01 09:28PM > for (unsigned i = 0; i <= len; ++i) > to[i] = from[i]; > } I think that strlen() is not a good example because there are good chances that the compiler will completely inline it. But anyway, your question relates to function calls that are not inlined. Are they functions in your code, or are they functions eg. from the standard library or something else? > (1) When building, at the linking stage just specify -l:libmonkey.so > (2) At runtime, call dlopen, LoadLibrary followed by dlsym, GetProcAddress > (3) Copy executable code into a shared memory object, and then just get other processes to map the shared memory and call the function Maybe the concept you are looking for is "position-independent code" (PIC). Compilers have an option for that, but I'm not sure it's enough for what you are trying to do. I think what you are trying to do would require your code to contain nothing that requires a dynamic linker (which is what PIC might or might not do, I'm not completely certain). |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 02 12:08AM +0200 On 01.08.2020 22:57, Frederick Gotham wrote: > [snip] > What I'm trying to do here is to come up with a third way of dynamically loading a shared library and executing code from it. Windows already does that automatically for you. - Alf |
| Scott Newman <scott69@gmail.com>: Aug 01 12:52PM +0200 >> you hope that then someone will respond saying that it is wrong. What >> happened to you? What made you that kind of miserable human being? > Don't feed the troll. Where am I trolling ? It's exactly as what I said: compiler for little -endian targets fill up bitfields beginning from the LSB, compilers for big-endian targets do it the opposite way. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 01 01:01PM > Where am I trolling ? It's exactly as what I said: compiler for little > -endian targets fill up bitfields beginning from the LSB, compilers for > big-endian targets do it the opposite way. So which one of those is gcc, and which one is Visual Studio, when they are compiling for the same target? |
| Scott Newman <scott69@gmail.com>: Aug 01 03:02PM +0200 > So which one of those is gcc, and which one is Visual Studio, > when they are compiling for the same target? I've shown here - <rg1peo$uj$1@dont-email.me> - that when they both target to x86 or x64, they both behave according to what I said. |
| Scott Newman <scott69@gmail.com>: Aug 01 03:08PM +0200 >> when they are compiling for the same target? > I've shown here - <rg1peo$uj$1@dont-email.me> - that when they both > target to x86 or x64, they both behave according to what I said. Here you can find the same statement: http://mjfrazer.org/mjfrazer/bitfields/ |
| Juha Nieminen <nospam@thanks.invalid>: Aug 01 09:21PM >> when they are compiling for the same target? > I've shown here - <rg1peo$uj$1@dont-email.me> - that when they both > target to x86 or x64, they both behave according to what I said. Which is what, exactly? How do they behave? |
| RM <robert_magdziarz@wp.pl>: Aug 01 02:55PM +0200 W dniu 31.07.2020 o 22:21, Mike Terry pisze: > stdout/stderr, so if you're not running under a suitable debugger the > messages would just be thrown away...) > Mike. I compiled dirtyphp.cpp under Linux Mint with -E option and I noticed that in dirtyphp.i file TRACE("main called" << endl); is expanded to single semicolon. This means that DEBUG symbol is undefined although I use -DDEBUG option of the compiler: debug: CXXFLAGS += -DDEBUG -g and I see this option during compilation: c++ -Wall -Wextra -Werror -no-pie -DDEBUG -g -Iinclude/ -c src/dirtyphp.cpp -o build/objects/src/dirtyphp.o -L/usr/lib -lstdc++ -lstdc++fs -lm c++ -Wall -Wextra -Werror -no-pie -DDEBUG -g -Iinclude/ -c src/common.cpp -o build/objects/src/common.o -L/usr/lib -lstdc++ -lstdc++fs -lm c++ -Wall -Wextra -Werror -no-pie -DDEBUG -g -Iinclude/ -c src/source_file.cpp -o build/objects/src/source_file.o -L/usr/lib -lstdc++ -lstdc++fs -lm c++ -Wall -Wextra -Werror -no-pie -DDEBUG -g -Iinclude/ -c src/obfuscator.cpp -o build/objects/src/obfuscator.o -L/usr/lib -lstdc++ -lstdc++fs -lm c++ -Wall -Wextra -Werror -no-pie -DDEBUG -g -o ./build/apps/dirtyphp build/objects/src/dirtyphp.o build/objects/src/common.o build/objects/src/source_file.o build/objects/src/obfuscator.o -L/usr/lib -lstdc++ -lstdc++fs -lm Here's my Makefile: #ifeq ($(ARCH),win32) ## Windows with the VC++ compiler #ObjSuf = obj #SrcSuf = cxx #ExeSuf = .exe #DllSuf = dll #OutPutOpt = -out: #CXX = cl #CXXOPT = -O2 #CXXOPT = -Z7 #CXXFLAGS = $(CXXOPT) -G5 -GR -GX -MD -DWIN32 -D_WINDOWS -nologo \ # -DVISUAL_CPLUSPLUS -D_X86_=1 -D_DLL #LD = link #LDOPT = -opt:ref #LDOPT = -debug #LDFLAGS = $(LDOPT) -pdb:none -nologo #SOFLAGS = -DLL CXX := -c++ # gcc czy g++? CXXFLAGS := -Wall -Wextra -Werror -no-pie # -pedantic-errors; add "-no-pie" to the CMAKE_CXX_FLAGS LDFLAGS := -L/usr/lib -lstdc++ -lstdc++fs -lm # -Lsrc/boost_1_65_0/lib/ -lboost_regex-gcc34-mt-d-1_3 BUILD := ./build OBJ_DIR := $(BUILD)/objects APP_DIR := $(BUILD)/apps TARGET := dirtyphp INCLUDE := -Iinclude/ # -I src/boost_1_65_0 SRC := $(wildcard src/*.cpp) OBJECTS := $(SRC:%.cpp=$(OBJ_DIR)/%.o) all: build $(APP_DIR)/$(TARGET) $(OBJ_DIR)/%.o: %.cpp @mkdir -p $(@D) $(CXX) $(CXXFLAGS) $(INCLUDE) -c $< -o $@ $(LDFLAGS) $(APP_DIR)/$(TARGET): $(OBJECTS) @mkdir -p $(@D) $(CXX) $(CXXFLAGS) -o $(APP_DIR)/$(TARGET) $^ $(LDFLAGS) .PHONY: all build clean debug release build: @mkdir -p $(APP_DIR) @mkdir -p $(OBJ_DIR) debug: CXXFLAGS += -DDEBUG -g debug: all test: CXXFLAGS += -pg # dodałem dynamic execution profiler test: all release: CXXFLAGS += -O2 release: all # production clean: -@rm -rvf $(OBJ_DIR)/* -@rm -rvf $(APP_DIR)/* |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 01 05:30PM +0200 On 01.08.2020 14:55, RM wrote: > clean: > -@rm -rvf $(OBJ_DIR)/* > -@rm -rvf $(APP_DIR)/* Uhm, the navigation in "solving problem" space is a bit haphazard. I've already provided you with a solution. Yet you persist in wasting time on it. - Alf |
| "The Doctor" <doctor@doctor.nl2k.ab.ca>: Aug 01 01:47PM XanaNews Statistic for comp.lang.c++. 8/1/2020 7:47:43 AM From article 417047 (7/1/2020 3:42:16 AM) to article 417545 (7/31/2020 4:22:21 PM) Number of threads ................... 48 Number of articles .................. 497 Average articles per thread ......... 10.35 Number of unanswered posts .......... 11 Number of posts from XanaNews users .. 1 Top Threads Ranking Articles Subject ------- -------- ---------------------------------- 1 107 Re: who's at fault, me or compiler? 2 55 c++ problem with dynamic and static object 3 33 What version of C++ 4 26 Re: Observable end padding in arrays 5 22 Conditional compilation - struct contains member 6 20 Are bitfields useful? 7 20 enum class or enum? 8 18 #ifdef with enum member 9 17 Fixing some undefined behavior 10 14 Interprocess communication 11 14 Re: Is this undefined behavior? 12 12 Link with library of exact filename (i.e. exact version) 13 10 Simple C++ Source Parser? 14 10 Mutex when returning by value 15 8 [Jesus Loves You] Some OT reading ... if interested 16 8 Should this compile? 17 8 conversion from 'int' to non-scalar type 'std::__cxx11::string 18 7 How to create and use thread pools for tasks? 19 7 Re: Users needed 20 7 This was my last post here in this newsgroup of C++ 21 7 More about our identity and about globalization and nationalism.. 22 6 More questions about operator overloading 23 6 XanaNews Statistic for comp.lang.c++. 7/1/2020 9:54:15 AM 24 5 About why is memory reclamation so important? 25 4 Read again, i correct about Delphi and Freepascal and volatile and safety.. 26 4 TRACE produces nothing 27 4 Re: C++ Freelance developer 28 4 About my posts 29 3 question for NRVO in if-branch 30 3 Read again, here is my final post about what is it to be smart ? 31 3 "Robust C++: P and V Considered Harmful" 32 3 Lock-Free Algorithms for Thread Safe Programming 33 3 About Wait-free and Lock-free and about OneFile.. 34 2 Re: urgent need for c/C++developer : Nashville TN, USA 35 2 Lockfree bounded LIFO stack and FIFO queue were updated to version 1.03 36 2 More about my new invention of a lock-free bounded LIFO stack algorithm.. 37 2 About safety and parallel programming.. Top Posters Ranking Articles Name Most Used Newsreader ------- -------- -------------------------- -------------------- 1 44 Öö Tiib G2 2 43 boltar@nowhere.co.uk 3 43 Juha Nieminen tin 4 37 Mr Flibble Mozilla 5 26 Keith Thompson Gnus 6 22 Scott Newman Mozilla 7 20 aminer68@gmail.com G2 8 19 Chris M. Thomasson Mozilla 9 18 woodbrian77@gmail.com G2 10 15 Paavo Helde Mozilla 11 14 Bo Persson Mozilla 12 13 James Kuyper Mozilla 13 12 Bonita Montero Mozilla 14 12 Frederick Gotham G2 15 12 Alf P. Steinbach Mozilla 16 11 David Brown Mozilla 17 11 Tim Rentsch Gnus 18 11 Ian Collins Mozilla 19 10 Jorgen Grahn slrn 20 9 Manfred Mozilla 21 8 Daniel P G2 22 5 Thiago Adams G2 23 5 RM Mozilla 24 4 Kenny McCormack trn 25 4 JiiPee Mozilla 26 4 The Real Non Homosexual G2 27 4 Stefan Ram 28 4 Barry Schwarz Forte Agent 29 4 already5chosen@yahoo.com G2 30 4 rick.c.hodgin@gmail.com G2 31 3 Fred. Zwarts Mozilla 32 3 aotto1968 Mozilla 33 3 IOP tin 34 2 Real Troll 35 2 Melzzzzz slrn 36 2 The Doctor trn 37 2 Pavel Mozilla 38 2 Ben Bacarisse 39 2 red floyd Mozilla 40 2 Vir Campestris Mozilla 41 2 bharathbhooshan.cm@gmail.c G2 42 2 Chris Vine Sylpheed 43 2 Lynn McGuire Mozilla 44 1 Marcel Mueller Mozilla 45 1 <iop@und.com> tin 46 1 just me Sylpheed 47 1 see.my....@gmail.com G2 48 1 Felix Palmen tin 49 1 Mike Terry Mozilla 50 1 Cholo Lennon Mozilla 51 1 Nikki Locke Nikkis auto poster 52 1 Siri Cruise MT-NewsWatcher 53 1 jacobnavia Mozilla 54 1 Ike Naar slrn 55 1 Sam http: 56 1 thomas.healy1987@gmail.com G2 57 1 Mike Copeland MicroPlanet-Gravity 58 1 ?? Good Guy ?? 59 1 anhonghe@gmail.com G2 Top Newsreaders Ranking Articles Newsreader Users ------- -------- -------------------------------------------- ----- 1 199 Mozilla 23 2 127 G2 14 3 52 <unknown> 5 4 48 tin 4 5 37 Gnus 2 6 13 slrn 3 7 5 trn 2 8 4 Forte Agent 1 9 3 Sylpheed 2 10 1 http: 1 11 1 MicroPlanet-Gravity 1 12 1 XanaNews 1 13 1 MT-NewsWatcher 1 14 1 Nikkis auto poster 1 -- This email has been checked for viruses by AVG. https://www.avg.com |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment