On Sat, 2006-09-09 at 16:52 +0100, Dave Korn wrote: > I think this would be a great feature to have, even if it did only work with > simple globals and couldn't handle TLS. > > Disclaimer: I haven't thought it through thoroughly yet :) Nor am I sure > whether the better solution might not be to just force all globals to be > accessed via the GOT and allow multiple GOT pointers? That would also keep
I am not sure what you are suggesting but unless we change in major ways the way ELF PIC works, we cannot allow multiple GOT pointers since the GOT is necessarily located at a fixed delta from the code base address. To have multiple GOT pointers, you need to have multiple code base addresses, that is, you need to map multiple times the same binary at multiple base addresses and make sure the dynamic loader also loads multiple times each library these binaries depend on. This is basically what some ELF systems implement as "loader namespaces". This is the solution I alluded when I refered to using magic ELF PIC tricks. There are 2 ways to implement this if you rebuild everything as PIC: 1) use dlmopen. The only problem is that the glibc version of dlmopen cannot accomodate more than 16 namespaces which would give me roughly 16 simulation processes per unix process. Nothing close to what I need. 2) rip out the glibc loader and change the dlmopen implementation to use a higher number of namespaces In both cases, the big problem is that the same function will then be located at two places in the virtual address space so, if you want to place a breakpoint in such a function, it will be cumbersome to make sure you break in every instance of that function. And it appears that this use-case is pretty common. i.e., the network guys I talked to about this solution went crazy because they spend their time putting a single breakpoint for all instances of a single function. > all the per-process data together, as opposed to grouping all the data for > each individual object across all processes together in an array, which might > be preferable. yes, it would be preferable but I don't see how to make it work (other than by running the same simulation twice: once to gather the memory requirements of the static area of each process and a second time to allocate the memory only once for each process). Mathieu
