- Help me override _exit in glibc - 2 Updates
- Can D simulated by H terminate normally? - 8 Updates
- Program with 3 threads mysteriously has 8 threads - 2 Updates
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jun 12 07:57AM -0700 When I want to execute some code at the very beginning of my program, I write an assembler function called 'pre_start', and then I do: g++ -o prog main.cpp my_compiled_assembler.o -e pre_start This allows me to do a few little things before glibc gets initialised. What I want to do now though, is that I want to do a few little things after glibc has totally shut down. I thought this would have been as simple as rewriting 'pre_start' as follows: pre_start: call __libc_start_main call __my_little_things_to_do syscall exit but it turns out that the function '__libc_start_main' never returns. Internally, it invokes '_exit' which performs a syscall to terminate the process. So I'm thinking that in order to do something after glibc has shut down, I will have to override _exit so that I can put a line or two of code right before the syscall to exit. I have written my own separate library which exports '_exit', and then I use LD_PRELOAD at the command line to load this library into my program. This doesn't work though -- glibc is still invoking its own '_exit' instead of mine. Will it be possible to get the glibc library to invoke my own '_exit' instead of the one that's built into libc.so.6? I want to try pull this off without editing and recompiling the source code for glibc. (Obviously I could edit the glibc source code and mark some symbols as weak, but for now I'm trying to pull this off without editing glibc). |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jun 12 04:07PM -0700 On Monday, June 12, 2023 at 3:57:20 PM UTC+1, Frederick Virchanza Gotham wrote: > So I'm thinking that in order to do something after glibc has shut down, > I will have to override _exit so that I can put a line or two of code right > before the syscall to exit. When my program first starts, before it calls '__libc_start_main', I print out the contents of "/proc/self/status". And then when my program ends, after all the 'atexit' functions and destructors have been called, I again want to print out the contents of "/proc/self/status". In order to print the file contents *without* using glibc, I use syscalls in x86_64 assembler. Here's the x86_64 assembler I've written to print out "/proc/self/status". I'm already able to call this function before jumping into "_start", but I also need to find out some way of calling it right before the "syscall(exit)" is invoked inside '__libc_start_main'. If anyone has any ideas on how to do this then please tell me. global PrintStatus:function PrintStatus: push r15 ; callee-saved - we shall restore later ; On the next 6 lines, I push the string "/proc/self/status" ; onto the stack 8 bytes at a time in Little Endian mov r15, 0x0000000000000073 ; "s" (with a null terminator) push r15 mov r15, 0x75746174732f666c ; "lf/statu" push r15 mov r15, 0x65732f636f72702f ; "/proc/se" push r15 ; On the next 5 lines, I do a 'syscall(read)' to open "/proc/self/status" mov rax, 2 ; open mov rdi, rsp ; path mov rsi, 0 ; flags mov rdx, 0 ; mode syscall ; The return value in RAX is the file descriptor, which I will save in r15 mov r15, rax ; If file descriptor is negative then bail out test r15, r15 js end_of_func start_loop: ; The next 5 lines read exactly 1 byte from the file mov rax, 0 ; read mov rdi, r15 ; fd mov rsi, rsp ; char * mov rdx, 1 ; count syscall ; The next two lines break out of the loop if less than 1 byte was read cmp rax, 1 jl end_of_func ; The next 5 lines write 1 byte to stdout mov rax, 1 ; write mov rdi, 1 ; fd = stdout mov rsi, rsp ; char const * mov rdx, 1 ; len syscall jmp start_loop end_of_func: add rsp, 24 ; take the string "/proc/self/status" back off the stack pop r15 ; restore the caller's original value of r15 ret |
| olcott <polcott2@gmail.com>: Jun 12 11:34AM -0500 Software engineers can easily verify that D correctly simulated by H cannot possibly reach its own line 09 and terminate normally. The x86utm operating system based on an open source x86 emulator. This system enables one C function to execute another C function in debug step mode. When H simulates D it creates a separate process context for D with its own memory, stack and virtual registers. H is able to simulate D simulating itself, thus the only limit to recursive simulations is RAM. // The following is written in C // 01 typedef int (*ptr)(); // pointer to int function 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input 03 04 int D(ptr x) 05 { 06 int Halt_Status = H(x, x); 07 if (Halt_Status) 08 HERE: goto HERE; 09 return Halt_Status; 10 } 11 12 void main() 13 { 14 D(D); 15 } *Execution Trace* Line 14: main() invokes D(D) *keeps repeating* (unless aborted) Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) *Simulation invariant* D correctly simulated by H cannot possibly reach its own line 09. Is it dead obvious to everyone here when examining the execution trace of lines 14 and 06 above that D correctly simulated by H cannot possibly terminate normally by reaching its own line 09? This means that when termination analyzer H aborts its simulation of D and reports that its correctly simulated input cannot possibly terminate normally it is merely reporting an easily verified fact. *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING* I will provide the next steps of the analysis after the above has been accepted. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 07:04PM +0200 Am 12.06.2023 um 18:34 schrieb olcott: > *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING* > I will provide the next steps of the analysis after the above has been > accepted. Does it get you anywhere, obsessing over the same detail for years? |
| olcott <polcott2@gmail.com>: Jun 12 12:27PM -0500 On 6/12/2023 12:04 PM, Bonita Montero wrote: >> I will provide the next steps of the analysis after the above has been >> accepted. > Does it get you anywhere, obsessing over the same detail for years? I have improved the wording such that anyone with a modicum of software engineering competence can easily verify that the above is necessarily correct. H(D,D) does correctly report that D correctly simulated by H cannot possibly terminate normally by reaching its own line 09. Also I finally have an easily understood rebuttal to the one remaining objection to my work that Ben Bacarisse has been so heavily pushing. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 12 08:30PM +0200 Am 12.06.2023 um 19:27 schrieb olcott: > cannot possibly terminate normally by reaching its own line 09. > Also I finally have an easily understood rebuttal to the one remaining > objection to my work that Ben Bacarisse has been so heavily pushing. How is that related to my question ? |
| olcott <polcott2@gmail.com>: Jun 12 01:53PM -0500 On 6/12/2023 1:30 PM, Bonita Montero wrote: >> objection to my work that Ben Bacarisse has been so heavily pushing. > How is that related to my question ? >>> Does it get you anywhere, obsessing over the same detail for years? *Yes it does here is how it does* Because I have focused on the issue of H(D,D) determining the halt status of its input for several years I have simplified my words so that anyone with a modicum of software engineering knowledge can easily verify that H(D,D) does correctly determine that D correctly simulated by H cannot possibly terminate normally. The latest (very recent) change is to switch the frame-of-reference from computer science halt deciders to software engineering termination analyzers. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 12 12:53PM -0700 On 6/12/2023 10:04 AM, Bonita Montero wrote: >> I will provide the next steps of the analysis after the above has been >> accepted. > Does it get you anywhere, obsessing over the same detail for years? No shit Bonita! wow. |
| olcott <polcott2@gmail.com>: Jun 12 03:21PM -0500 On 6/12/2023 2:53 PM, Chris M. Thomasson wrote: >> Does it get you anywhere, obsessing over the same detail for years? > No shit Bonita! wow. >>> Does it get you anywhere, obsessing over the same detail for years? *Yes it does here is how it does* Because I have focused on the issue of H(D,D) determining the halt status of its input for several years I have simplified my words so that anyone with a modicum of software engineering knowledge can easily verify that H(D,D) does correctly determine that D correctly simulated by H cannot possibly terminate normally. The latest (very recent) change is to switch the frame-of-reference from computer science halt deciders to software engineering termination analyzers. The whole system is right here: https://github.com/plolcott/x86utm It compiles with the 2017 version of the Community Edition https://visualstudio.microsoft.com/vs/older-downloads/ -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Big Dick <Big.Dick@olcott.crap>: Jun 12 10:45PM +0100 On 12/06/2023 18:04, Bonita Montero wrote: > Does it get you anywhere, obsessing over the same detail for years? He once said he gets a very hard erection to attend Bunga Bunga sex party organised by late Silvio Berlusconi of Italy. He can show his prowess in C programming at these parties. |
| Christian Gollwitzer <auriocus@gmx.de>: Jun 12 07:27AM +0200 Am 11.06.23 um 23:38 schrieb Frederick Virchanza Gotham: > 6 Thread 0x7fffee86e6c0 (LWP 115895) "dynamo" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 > 7 Thread 0x7fffee06d6c0 (LWP 115896) "dynamo" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 > I tried issuing the command "thread apply all bt" but I'm not sure about what it comes back with -- it seems like some of the threads might be spawned inside libglib. I suspect that the "extra" threads are spawned by wxWidgets or GTK in order to wait for specific events. It is not uncommon to do that in order to integrate an event source into the main event loop. "gdbus", e.g., is a library for interaction with the DBus process intercommunication system. Christian |
| scott@slp53.sl.home (Scott Lurndal): Jun 12 02:55PM >I'm writing a complex program at the moment and I want it to be absolutely bulletproof, so I'm using tools to find all memory leaks, all data races, etc. Mostly I'm using "-fsanitize" with g++. >My program has the main GUI thread, the Listener thread for reading from the network card, and the Sender thread for sending packets out on the network card. So that's three threads. >Sometimes my program shows as many as 8 threads. I don't know where these other 5 threads are being spawned nor what they're doing? What do you mean by "shows"? The ps(1) or top(1) commands or some internal logic in your application? >How would you go about figuring this out? I'm using the latest Ubuntu Linux on x86_64. run the program under gdb and (gdb) thread apply all bt |
| 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