Dmitry V. Levin wrote:
> On Sat, Nov 02, 2013 at 05:43:50PM +0000, John Spencer wrote:
>> on a 64 bit linux system, with musl libc (off_t is long long), the 
>> following happens:
>>
>> configure:6234: checking for long long off_t
>> conftest.c:42:6: error: size of array 'a' is negative
>>
>> | #include <sys/types.h>
>> | char a[(sizeof (off_t) == sizeof (long long) &&
>> |         sizeof (off_t) > sizeof (long)) - 1];
>> |
>>
>> configure:6254: result: no
>>
>> the problem is the second part of the check, which is completely bogus 
>> on a 64bit system, where sizeof long long == sizeof long.
> 
> This is expected behaviour.  AC_OFF_T_IS_LONG_LONG checks whether long type
> has enough room for off_t, or long long type is required instead.  It has
> nothing to do with the way how off_t is actually defined in the system.
> AC_OFF_T_IS_LONG_LONG was added to strace 12.5 years ago so the name
> of this macro might be slightly misleading nowadays.
> 
> By the way, starting with commit v4.8~83, strace no longer uses
> HAVE_LONG_LONG_OFF_T so the check could be safely removed.

that's good news.

> 
>> btw, while you're at it please consider merging this compatibility patch:
>> http://git.alpinelinux.org/cgit/aports/plain/main/strace/strace-musl.patch
>> (author is Timo Teräs <[email protected]>)
> 
> That patch is not obvious to say the least.  Could you or the author
> clarify the meaning of each change, please?
> 
> 

-    ) && defined(__GLIBC__)
+    ) && defined(__linux__)
  # include <sys/ptrace.h>

apparently without including this header, ptrace defines are missing.

a better check would be if configure checks if the header is available, 
instead of the entire ifdeffery.

-#if _LFS64_LARGEFILE
+#if defined _LFS64_LARGEFILE || defined HAVE_LONG_LONG_OFF_T
  int
  sys_truncate64(struct tcb *tcp)

musl has off_t always as long long (and obviously isnt glibc).
without this patch, we get a link error that sys_truncate64 is missing.
so maybe it would be better if configure checks whether sizeof(off_t) == 
sizeof(int64_t).

-#if _LFS64_LARGEFILE
+#if defined _LFS64_LARGEFILE || defined HAVE_LONG_LONG_OFF_T
  int
  sys_getdents64(struct tcb *tcp)
likewise.

  /* Under Linux these are enums so we can't test for them with ifdef. */
+#if !defined(IPPROTO_MAX)
not under linux, but under glibc. musl defines those as macros.

-                       tprintf(", { %d }", p.__sched_priority);
+                       tprintf(", { %d }", p.sched_priority);
accessing a glibc internal symbol.

-               execl(_PATH_BSHELL, "sh", "-c", command, NULL);
+               execl(_PATH_BSHELL, "sh", "-c", command, (void*) 0);
NULL is not a valid sentinel for execl.
execl expects char* parameters, not (void*) 0, (char) 0, 0L, 0LL, (enum 
foobar) 0 or whatever the C standard allows it to be.
citation of the C standard is available here: http://ewontfix.com/11/

this is not a build error but a warning fix.
the proper fix would be (char*) 0.
apparently the author just wanted to shut up gcc.

-#if defined(AARCH64)
-# include <asm/ptrace.h>
-#endif
-
-#if defined(XTENSA)
-# include <asm/ptrace.h>
-#endif
+#include <asm/ptrace.h>
seems asm/ptrace.h is required anyway to not get a build error.
and on glibc/uclibc, including it unconditionally doesnt hurt as well.

+#if defined(__GLIBC__)
                        tprintf("{%d}", sev._sigev_un._pad[0]);
+#else
+                       tprintf("{%d}", (int) sev.__pad[0]);
+#endif
another glibc implementation specific internal struct member.
since the musl one is __ prefixed as well, i wonder if there's a clean 
fix for this. i suspect though that the __pad macro was added for glibc
compat, so sev.__pad[0] may work on all linux libcs.

thanks,
--JS

P.S. the musl tarball comes with a musl-gcc wrapper which makes it easy 
to test.


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Strace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strace-devel

Reply via email to