[Bug general/21010] New: Incompatible with MUSL libc: strerror_r

[luizluca at gmail dot com]

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

Bug ID: 21010
   Summary: Incompatible with MUSL libc: strerror_r
   Product: elfutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: general
  Assignee: unassigned at sourceware dot org
  Reporter: luizluca at gmail dot com
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

>From original bug 21002

- I have to think about that strerror_r replacement. Normally we expect just a
static string describing a known errno. But I see we have to handle unknown
numbers too. hmmm.

The used behavior is GNU-specific:

   The GNU-specific strerror_r() returns a pointer to a string containing
the error message.  This may be either a pointer to a string that the function
stores  in  buf,  or  a  pointer  to  some
   (immutable)  static  string (in which case buf is unused).  If the
function stores a string in buf, then at most buflen bytes are stored (the
string may be truncated if buflen is too small and
   errnum is unknown).  The string always includes a terminating null byte
('\0').

A portable way to solve this is stick to the XSI-compliant behavior (as in the
patch).

--- a/libdwfl/dwfl_error.c
+++ b/libdwfl/dwfl_error.c
@@ -140,6 +140,7 @@ __libdwfl_seterrno (Dwfl_Error error)
 const char *
 dwfl_errmsg (int error)
 {
+  static __thread char s[64] = "";
   if (error == 0 || error == -1)
 {
   int last_error = global_error;
@@ -154,7 +155,8 @@ dwfl_errmsg (int error)
   switch (error &~ 0x)
 {
 case OTHER_ERROR (ERRNO):
-  return strerror_r (error & 0x, "bad", 0);
+  strerror_r (error & 0x, s, sizeof(s));
+  return s;
 case OTHER_ERROR (LIBELF):
   return elf_errmsg (error & 0x);
 case OTHER_ERROR (LIBDW):


However, according to the comments on the original bug, it might be interesting
to find a new way to deal with it.

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

[Bug general/21008] Incompatible with MUSL libc: error.h and error() not provided

[luizluca at gmail dot com]

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

--- Comment #1 from Luiz Angelo Daros de Luca  ---
BTW, simply moving the include into system.h will dramatically reduce the
number of files I need to patch in order to compile with MUSL.

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

The elfutils-devel mailinglist is now at sourceware.

[Mark Wielaard]

Hi elfutils hackers,

The elfutils-devel mailinglist is now hosted at sourceware.
https://sourceware.org/ml/elfutils-devel/

Everybody subscribed to the old elfutils-devel hosted at
lists.fedorahosted.org has been subscribed to the new list.

This is the last message to go to the old list.
Everybody will be unsubscribed after this message.
So you will only get this message twice on both the old
and the new list.

If you are reading this list in another way then you can
subscribe to the new elfutils-devel list by either sending
and email to elfutils-devel-subscr...@sourceware.org or use
the form at https://sourceware.org/lists.html#ml-requestor

See you on the other side!

Mark

[Bug general/21009] Incompatible with MUSL libc: canonicalize_file_name

[luizluca at gmail dot com]

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

Luiz Angelo Daros de Luca  changed:

   What|Removed |Added

 Blocks||21002


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=21002
[Bug 21002] Incompatible with MUSL libc
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21008] Incompatible with MUSL libc: error.h and error() not provided

[luizluca at gmail dot com]

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

Luiz Angelo Daros de Luca  changed:

   What|Removed |Added

 Blocks||21002


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=21002
[Bug 21002] Incompatible with MUSL libc
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21010] Incompatible with MUSL libc: strerror_r

[luizluca at gmail dot com]

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

Luiz Angelo Daros de Luca  changed:

   What|Removed |Added

 Blocks||21002


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=21002
[Bug 21002] Incompatible with MUSL libc
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21002] Incompatible with MUSL libc

[luizluca at gmail dot com]

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

Luiz Angelo Daros de Luca  changed:

   What|Removed |Added

 Depends on||21008, 21009, 21010

--- Comment #4 from Luiz Angelo Daros de Luca  ---
- error(): created a new bug 21008

- canonicalize_file_name(): create a new bug 21009

- strerror_r: create a new bug 21010

- strndupa is provided by MUSL if defined _GNU_SOURCE. Not a problem anymore
  https://github.com/esmil/musl/blob/master/include/string.h#L89

Until now, I still only tested compiling elfutils libraries.


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=21008
[Bug 21008] Incompatible with MUSL libc: error.h and error() not provided
https://sourceware.org/bugzilla/show_bug.cgi?id=21009
[Bug 21009] Incompatible with MUSL libc: canonicalize_file_name
https://sourceware.org/bugzilla/show_bug.cgi?id=21010
[Bug 21010] Incompatible with MUSL libc: strerror_r
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

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

Bug ID: 21011
   Summary: "may be used uninitialized" error with
-Werror=maybe-uninitialized
   Product: elfutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: general
  Assignee: unassigned at sourceware dot org
  Reporter: luizluca at gmail dot com
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

Hello,

I get this error when compiling with -Werror=maybe-uninitialized

elf_getarsym.c: In function 'elf_getarsym':
elf_getarsym.c:200:14: error: 'n' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   size_t ar_sym_len = (n + 1) * sizeof (Elf_Arsym);


I know that read_number_entries define its values unconditionally but it won't
hurt to simply use:

  uint64_t n = 0;

Is it ok?

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

Re: The elfutils-devel mailinglist is now at sourceware.

[Kurt Roeckx]

On Fri, Dec 30, 2016 at 10:25:42PM +0100, Mark Wielaard wrote:
> Hi elfutils hackers,
> 
> The elfutils-devel mailinglist is now hosted at sourceware.
> https://sourceware.org/ml/elfutils-devel/
> 
> Everybody subscribed to the old elfutils-devel hosted at
> lists.fedorahosted.org has been subscribed to the new list.

This list doesn't has a List-Id, can this be fixed?

The headers show:
Mailing-List: contact elfutils-devel-h...@sourceware.org; run by ezmlm
Precedence: bulk
List-Post: 
List-Help: 
List-Unsubscribe: 
List-Subscribe: 

While the old one has:
Precedence: list
List-Id: List for developers of elfutils 
Archived-At: 

List-Archive: 

List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 

As far as I know, the List-Id is what you really want.


Kurt

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

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

--- Comment #1 from Luiz Angelo Daros de Luca  ---
Another case:

i386_disasm.c: In function 'i386_disasm':
/home/luizluca/prog-local/lede/trunk/staging_dir/toolchain-mipsel_24kc_gcc-5.4.0_musl-1.1.15/include/fortify/string.h:47:24:
error: 'str' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
  (__s < __d && __s + __n > __d))

i386_disasm.c:709:17: note: 'str' was declared here
 const char *str;


This is because of missing:

--- a/libcpu/i386_disasm.c
+++ b/libcpu/i386_disasm.c
@@ -822,6 +822,7 @@ i386_disasm (Ebl *ebl __attribute__((unu
  /* Fallthrough */
default:
  assert (! "INVALID not handled");
+ str = "";
}
}
  else

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

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[pmachata at gmail dot com]

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

--- Comment #2 from pmachata at gmail dot com ---
On Dec 31, 2016 00:14, "luizluca at gmail dot com" <
sourceware-bugzi...@sourceware.org> wrote:

--- a/libcpu/i386_disasm.c
+++ b/libcpu/i386_disasm.c
@@ -822,6 +822,7 @@ i386_disasm (Ebl *ebl __attribute__((unu
  /* Fallthrough */
default:
  assert (! "INVALID not handled");
+ str = "";


Or abort() instead? The point is that the assert always fails. Which it
does, unless you compile with -DNDEBUG. So just force it?

Thanks,
Petr

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

[Bug general/21002] Incompatible with MUSL libc

[luizluca at gmail dot com]

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

--- Comment #5 from Luiz Angelo Daros de Luca  ---
It is not part of my use case but besides the problems already mentioned,
elfutils/src will still miss from glibc:

- obstack
- fts (I already use a patch to remove its dependency on lib*)

The approach used by voidlinux is to create independent libraries and checking
for them on ./configure as in
https://github.com/voidlinux/void-packages/blob/master/srcpkgs/elfutils/patches/musl-fts-obstack.patch

If I manually remove src from Makefile, everything else builds nicely.

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