[Bug dynamic-link/30100] [patch] add dlmem()

["stsp at users dot sourceforge.net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30100

--- Comment #32 from Stas Sergeev <stsp at users dot sourceforge.net> ---
https://sourceware.org/pipermail/libc-alpha/2023-March/146434.html
Posted a v9 with lots of new features.
Also its better structured for a review.
Namely the shm-dealing stuff is in the
patch 13, outside of the main dlmem()
impl. As this shm-dealing seems to be
the last part still not well understood,
I put it separately, with a separate
test-case. Which, as before, maps the
lib twice.

Also patch 12 has an fdlopen() impl as
a test-case:

static void *
fdlopen (int fd, int flags)
{
  off_t len;
  void *addr;
  void *handle;

  len = lseek (fd, 0, SEEK_END);
  lseek (fd, 0, SEEK_SET);
  addr = mmap (NULL, len, PROT_READ, MAP_PRIVATE, fd, 0);
  if (addr == MAP_FAILED)
    {
      printf ("cannot mmap, %s\n", strerror(errno));
      exit (EXIT_FAILURE);
    }
  handle = dlmem (addr, len, flags, NULL);
  munmap (addr, len);
  return handle;
}


Neither fdlopen() nor solib duplication can
be done with intercepting the first mmap.
Also I wonder if fdlopen() can ever be
implemented simpler than that. :) The test-case
for fdlopen() makes sure that /proc/self/maps
have the right references to the loaded solib,
rather than some anonymously mapped areas, which
would be a cheating.
So in fact dlmem() have suddenly grown into
an universal tool that exposes all the former
and new libdl features via the single small
call. It can handle file-based solibs not
any worse than the memory-based ones (you
can even specify the solib name now).
So basically, a huge libdl superset by the
price of just 1 call!

-- 
You are receiving this mail because:
You are on the CC list for the bug.