[Bug libelf/23903] New: Uses linux specifc mremap

[Bug libelf/23903] New: Uses linux specifc mremap

[kurt at roeckx dot be]

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

            Bug ID: 23903
           Summary: Uses linux specifc mremap
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libelf
          Assignee: unassigned at sourceware dot org
          Reporter: kurt at roeckx dot be
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

In Debian's kfreebsd ports, I'm getting:
/usr/bin/ld: libelf_pic.a(elf_update.os): in function `write_file':
./libelf/elf_update.c:109: undefined reference to `mremap'

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

[Bug libelf/23903] Uses linux specifc mremap

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
That is a weird error. It means you could compile fine as if mremap was
available, but only during linking it is suddenly discovered that there is no
mremap?

mremap is needed for supporting ELF_C_RDWR_MMAP with ELF files that grow. See
for example the tests/run-copyadd-sections.sh and
tests/run-copymany-sections.sh testcases (and the explanation in the second why
we don't use ELF_C_RDWR_MMAP). mremap is used because it is the only way to
extend an mmap without moving it.

Even on GNU/Linux mremap might fail, in which case writing out an
ELF_C_RDWR_MMAPed ELF file might just not work (it normally works when
extending the file a little, but not when multiple pages are needed).

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

[Bug libelf/23903] Uses linux specifc mremap

[kurt at roeckx dot be]

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

--- Comment #2 from Kurt Roeckx <kurt at roeckx dot be> ---
Note that Debian's kfreebsd port uses glibc. Maybe they have mremap() in the
header even when it's not actually in the library?

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

[Bug libelf/23903] Uses linux specifc mremap

[kurt at roeckx dot be]

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

--- Comment #3 from Kurt Roeckx <kurt at roeckx dot be> ---
On Hurd I get:
/usr/bin/ld: libelf_pic.a(elf32_updatefile.os): in function
`__elf32_updatemmap':
./libelf/elf32_updatefile.c:462: warning: msync is not implemented and will
always fail
/usr/bin/ld: libelf_pic.a(elf_update.os): in function `write_file':
./libelf/elf_update.c:109: undefined reference to `mremap'

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

[Bug libelf/23903] Uses linux specifc mremap

[mark at klomp dot org]

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

--- Comment #4 from Mark Wielaard <mark at klomp dot org> ---
Having an msync that doesn't write out changes to a file is bad, but you might
get away with it in most cases (the changes should be written to disk when
munmap is called).

You do need a mremap function, even if it always fails.

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

[Bug libelf/23903] Uses linux specifc mremap

[kurt at roeckx dot be]

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

--- Comment #5 from Kurt Roeckx <kurt at roeckx dot be> ---
Since I don't have it, it will make this a Linux only package. This at least
means that currently glib2.0 and rpm will also not be able to get build on
non-Linux platforms. This is really a Linux specific system call.

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

[Bug libelf/23903] Uses linux specifc mremap

[mark at klomp dot org]

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

--- Comment #6 from Mark Wielaard <mark at klomp dot org> ---
It is fine for elfutils to have GNU/Linux specific code since that is the
primary target. But if other platforms provide needed functionality in a
different way then patches are obviously more than welcome. In the case of
mremap you could even get away with something that always fails. Which would
probably work just fine for Hurd, but for kfreebsd you really need to figure
out first why it seems to provide a mremap function but then fails while
linking. Otherwise it will be hard to know when/why to provide an alternative.

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

[Bug libelf/23903] Uses linux specifc mremap

[kurt at roeckx dot be]

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

--- Comment #7 from Kurt Roeckx <kurt at roeckx dot be> ---
I've filed a bug in Debian about mremap() being in the headers, so that should
hopefully get fixed. But that will not fix the problem, it will either now just
generate a warning that it doesn't have a prototype, or give a compilation
error.

It seems to me that we want to detect in configure that mremap() exists, and if
it doesn't disable the use of mmap.

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

[Bug libelf/23903] Uses linux specifc mremap

[bibi584762 at gmail dot com]

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

Jean Michault <bibi584762 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bibi584762 at gmail dot com

--- Comment #8 from Jean Michault <bibi584762 at gmail dot com> ---
Created attachment 11932
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11932&action=edit
patch to allow compile on systems without mremap

I suggest the patch attached.
This makes it possible to compile elfutils on nonlinux systems, but generates
an error if one tries to use features that need mremap.

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

[Bug libelf/23903] Uses linux specifc mremap

[mark at klomp dot org]

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

--- Comment #9 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Jean Michault from comment #8)
> Created attachment 11932 [details]
> patch to allow compile on systems without mremap
> 
> I suggest the patch attached.
> This makes it possible to compile elfutils on nonlinux systems, but
> generates an error if one tries to use features that need mremap.

Thanks. Some questions about the proposed patch:
- What defines HAVE_MMAP?
  I don't believe we currently have a configure check for it, should we?
- The guard checks for HAVE_MMAP, but the code calls mremap.
  Should we have a HAVE_MREMAP guard and configure check instead?
- On which systems did you test and what were the make check results?

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

[Bug libelf/23903] Uses linux specifc mremap

[bibi584762 at gmail dot com]

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

--- Comment #10 from Jean Michault <bibi584762 at gmail dot com> ---
(In reply to Mark Wielaard from comment #9)
> (In reply to Jean Michault from comment #8)
> > Created attachment 11932 [details]
> > patch to allow compile on systems without mremap
> > 
> > I suggest the patch attached.
> > This makes it possible to compile elfutils on nonlinux systems, but
> > generates an error if one tries to use features that need mremap.
> 
> Thanks. Some questions about the proposed patch:
> - What defines HAVE_MMAP?
>   I don't believe we currently have a configure check for it, should we?
> - The guard checks for HAVE_MMAP, but the code calls mremap.
>   Should we have a HAVE_MREMAP guard and configure check instead?
> - On which systems did you test and what were the make check results?

You're right, i was a little too fast, you can have mmap without having mremap,
so you have to test mremap. And we need to add the mremap test in configure.ac.
I will work again.

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

[Bug libelf/23903] Uses linux specifc mremap

[bibi584762 at gmail dot com]

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

Jean Michault <bibi584762 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #11932|0                           |1
        is obsolete|                            |

--- Comment #11 from Jean Michault <bibi584762 at gmail dot com> ---
Created attachment 11933
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11933&action=edit
patch to allow compile on systems without mremap

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

[Bug libelf/23903] Uses linux specifc mremap

[bibi584762 at gmail dot com]

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

--- Comment #12 from Jean Michault <bibi584762 at gmail dot com> ---
(In reply to Mark Wielaard from comment #9)
> (In reply to Jean Michault from comment #8)
> > Created attachment 11932 [details]
> > patch to allow compile on systems without mremap
> > 
> > I suggest the patch attached.
> > This makes it possible to compile elfutils on nonlinux systems, but
> > generates an error if one tries to use features that need mremap.
> 
> Thanks. Some questions about the proposed patch:
> - What defines HAVE_MMAP?
>   I don't believe we currently have a configure check for it, should we?
> - The guard checks for HAVE_MMAP, but the code calls mremap.
>   Should we have a HAVE_MREMAP guard and configure check instead?
> - On which systems did you test and what were the make check results?

I propose another patch that checks mremap.
I tested on a debian system GNU / Hurd 2019. The compilation is going well but
some tests fail:

============================================================================
Testsuite summary for elfutils 0.176
============================================================================
# TOTAL: 205
# PASS:  170
# SKIP:  23
# XFAIL: 0
# FAIL:  12
# XPASS: 0
# ERROR: 0

failing tests are :
FAIL: run-readelf-loc.sh
FAIL: run-readelf-ranges.sh
FAIL: run-bug1-test.sh
FAIL: run-varlocs.sh
FAIL: run-allfcts-multi.sh
FAIL: elfstrtab
FAIL: emptyfile
FAIL: run-get-units-split.sh
FAIL: run-attr-integrate-skel.sh
FAIL: run-all-dwarf-ranges.sh
FAIL: run-unit-info.sh
FAIL: run-copyadd-sections.sh

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

[Bug libelf/23903] Uses linux specifc mremap

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2019-08-09
           Assignee|unassigned at sourceware dot org   |mark at klomp dot org
     Ever confirmed|0                           |1

--- Comment #13 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Jean Michault from comment #12)
> I propose another patch that checks mremap.

That looks perfectly reasonable. Thanks.

It isn't really necessary for such small patches, but would you mind taking a
look at our CONTRIBUTING file and let me know if you are OK with your
Signed-off-by for this patch?
https://sourceware.org/git/?p=elfutils.git;a=blob_plain;f=CONTRIBUTING;hb=HEAD

> I tested on a debian system GNU / Hurd 2019. The compilation is going well
> but some tests fail:
> 
> ============================================================================
> Testsuite summary for elfutils 0.176
> ============================================================================
> # TOTAL: 205
> # PASS:  170
> # SKIP:  23
> # XFAIL: 0
> # FAIL:  12
> # XPASS: 0
> # ERROR: 0
> 
> failing tests are :
> FAIL: run-readelf-loc.sh
> FAIL: run-readelf-ranges.sh
> FAIL: run-bug1-test.sh
> FAIL: run-varlocs.sh
> FAIL: run-allfcts-multi.sh
> FAIL: elfstrtab
> FAIL: emptyfile
> FAIL: run-get-units-split.sh
> FAIL: run-attr-integrate-skel.sh
> FAIL: run-all-dwarf-ranges.sh
> FAIL: run-unit-info.sh
> FAIL: run-copyadd-sections.sh

I would expect run-copyadd-sections to fail (because it explicitly tests this
code path and will fail if mremap fails). But some of the others are
surprising. Would you mind attaching the tests/test-suite.log file so we can
inspect how exactly these tests fail?

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

[Bug libelf/23903] Uses linux specifc mremap

[mark at klomp dot org]

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

--- Comment #14 from Mark Wielaard <mark at klomp dot org> ---
Hi Jean Michault,

I am still interested getting this patch in. Could you look at comment #13 to
see if the CONTRIBUTING text makes sense and if you could provide the
tests/test-suite.log file to analyze the results a bit better.

Thanks,

Mark

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

[Bug libelf/23903] Uses linux specifc mremap

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #15 from Mark Wielaard <mark at klomp dot org> ---
This was resolved for the similar bug #27337

*** This bug has been marked as a duplicate of bug 27337 ***

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