[OE-core] ✗ patchtest: failure for nasm: Fix pure function warnings

[Patchwork]

== Series Details ==

Series: nasm: Fix pure function warnings
Revision: 1
URL   : https://patchwork.openembedded.org/series/11635/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Upstream-Status is Submitted, but it is not mentioned where 
[test_upstream_status_presence_format] 
  Suggested fixInclude where 
0001-asmlib-Drop-pure-function-attribute-from-seg_init.patch was submitted
  Current  Upstream-Status: Submitted
  Standard format  Upstream-Status: Submitted [where]



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] nasm: Fix pure function warnings

[Khem Raj]

Signed-off-by: Khem Raj 
---
 ...rop-pure-function-attribute-from-seg_init.patch | 27 ++
 meta/recipes-devtools/nasm/nasm_2.13.03.bb |  4 +++-
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/nasm/nasm/0001-asmlib-Drop-pure-function-attribute-from-seg_init.patch

diff --git 
a/meta/recipes-devtools/nasm/nasm/0001-asmlib-Drop-pure-function-attribute-from-seg_init.patch
 
b/meta/recipes-devtools/nasm/nasm/0001-asmlib-Drop-pure-function-attribute-from-seg_init.patch
new file mode 100644
index 00..12ae3a94df
--- /dev/null
+++ 
b/meta/recipes-devtools/nasm/nasm/0001-asmlib-Drop-pure-function-attribute-from-seg_init.patch
@@ -0,0 +1,27 @@
+From 77c3a77210d8ca8b94e999c711156e984a8dc737 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sat, 31 Mar 2018 11:05:33 -0700
+Subject: [PATCH] asmlib: Drop pure function attribute from seg_init
+
+seg_init returns void, so it is impure function
+
+Signed-off-by: Khem Raj 
+---
+Upstream-Status: Submitted
+
+ include/nasmlib.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/nasmlib.h b/include/nasmlib.h
+index 79e866b..b80b7e2 100644
+--- a/include/nasmlib.h
 b/include/nasmlib.h
+@@ -191,7 +191,7 @@ int64_t readstrnum(char *str, int length, bool *warn);
+  * seg_init: Initialise the segment-number allocator.
+  * seg_alloc: allocate a hitherto unused segment number.
+  */
+-void pure_func seg_init(void);
++void seg_init(void);
+ int32_t pure_func seg_alloc(void);
+ 
+ /*
diff --git a/meta/recipes-devtools/nasm/nasm_2.13.03.bb 
b/meta/recipes-devtools/nasm/nasm_2.13.03.bb
index 3a47fc9c88..236d7e5e36 100644
--- a/meta/recipes-devtools/nasm/nasm_2.13.03.bb
+++ b/meta/recipes-devtools/nasm/nasm_2.13.03.bb
@@ -3,7 +3,9 @@ SECTION = "devel"
 LICENSE = "BSD-2-Clause"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=90904486f8fbf1861cf42752e1a39efe"
 
-SRC_URI = "http://www.nasm.us/pub/nasm/releasebuilds/${PV}/nasm-${PV}.tar.bz2 "
+SRC_URI = "http://www.nasm.us/pub/nasm/releasebuilds/${PV}/nasm-${PV}.tar.bz2 \
+   file://0001-asmlib-Drop-pure-function-attribute-from-seg_init.patch 
\
+   "
 
 SRC_URI[md5sum] = "0c581d482f39d5111879ca9601938f74"
 SRC_URI[sha256sum] = 
"63ec86477ad3f0f6292325fd89e1d93aea2e2fd490070863f17d48f7cd387011"
-- 
2.16.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

[Seebs]

On Sat, 31 Mar 2018 16:03:01 -0500
Joshua Watt  wrote:

> Looks like maybe gdk-pixbuf-query-loaders has the unlucky honour of
> being one of the few programs that invokes the pseudo syscall()
> wrapper before any other functions that pseudo wraps and the missing
> initializer made it explode?

That seems exceedingly likely, because indeed, that's supposed to be at
the top of the wrapper. Thanks.

-s
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

[Joshua Watt]

On Sat, Mar 31, 2018 at 8:12 AM, Richard Purdie
 wrote:
> Just to report back, I've tried testing an earlier version of pseudo
> master with the path changes reverted and current master. With both I'm
> seeing librsvg fail during do_install with a segfault (you have to
> remove the 2> /dev/null to see it).
>
> I'm seeing multiple entries in the host's dmesg:
>
> [180364.269879] glib-compile-re[38258]: segfault at 0 ip   (null) sp 
> 7aafbf78 error 14 in glib-compile-resources[55abc201b000+9000]
> [180376.499904] glib-compile-re[46860]: segfault at 0 ip   (null) sp 
> 7ffd3b10f2c8 error 14 in glib-compile-resources[55b2cb528000+9000]
> [180376.612404] glib-compile-re[46862]: segfault at 0 ip   (null) sp 
> 7fff612977f8 error 14 in glib-compile-resources[55ad08797000+9000]
> [180376.726317] glib-compile-re[46864]: segfault at 0 ip   (null) sp 
> 7ffdce018928 error 14 in glib-compile-resources[5610851ec000+9000]
> [180376.836705] glib-compile-re[46866]: segfault at 0 ip   (null) sp 
> 7ffc586fdda8 error 14 in glib-compile-resources[562f38dfc000+9000]
> [180603.294668] gdk-pixbuf-quer[51620]: segfault at 0 ip   (null) sp 
> 7ffce7947fe8 error 14 in gdk-pixbuf-query-loaders.real[55b88bb7f000+2000]
> [185206.227285] gdk-pixbuf-quer[51885]: segfault at 0 ip   (null) sp 
> 7ffe6393ae28 error 14 in gdk-pixbuf-query-loaders.real[556db9ae3000+2000]
> [186523.735264] gdk-pixbuf-quer[70272]: segfault at 0 ip   (null) sp 
> 7fff6a855808 error 14 in gdk-pixbuf-query-loaders.real[55ec4e8fd000+2000]
>
> I believe that libglib-2.0 does use syscall() for something and that
> the above programs are calling into it and faulting.
>
> Its likely possible to reproduce this outside of a build by running
> make install from librsvg under pseudo.
>
> If I take master and revert 778abd3686fb7c419e9016fdd9e93819405d52aa fr
> om pseudo, it no longer segfaults.
>
> So something is not working correctly with the intercept sadly.

I had a little time and it was easy for me to reproduce this. It looks
like real_syscall in pseudo is still NULL meaning it wasn't
initialized:

$ coredumpctl gdb -1
...
Core was generated by
`/home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x7f1c013debfb in syscall (number=140726086677920) at
ports/linux/pseudo_wrappers.c:71
#2  0x7f1c0071737f in g_once_init_leave ()
   from 
/home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../libglib-2.0.so.0
#3  0x7f1c009c615d in g_value_array_get_type ()
   from 
/home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../libgobject-2.0.so.0
#4  0x7f1c009d7478 in ?? () from
/home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../libgobject-2.0.so.0
#5  0x7f1c009c41ac in ?? () from
/home/jwatt/Development/poky/build/tmp/work/i586-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../libgobject-2.0.so.0
#6  0x7f1c01628f8a in ?? () from
/home/jwatt/Development/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
#7  0x7f1c01629096 in ?? () from
/home/jwatt/Development/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
#8  0x7f1c0161b06a in ?? () from
/home/jwatt/Development/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
#9  0x0002 in ?? ()
#10 0x7ffd58684fd4 in ?? ()
#11 0x7ffd58685069 in ?? ()
#12 0x in ?? ()
(gdb) p real_syscall
$1 = (long (*)(long, ...)) 0x0

I'm not very familiar with the internal of how pseudo works, but
adding this to the beginning of the syscall wrapper function in
ports/linux/pseudo_wrappers.c fixed it for me (no idea if this is the
"right" fix):

if (!pseudo_check_wrappers() || !real_syscall) {
/* rc was initialized to the "failure" value */
pseudo_enosys("syscall");
PROFILE_DONE;
errno = ENOSYS;
return -1;
}

Looks like maybe gdk-pixbuf-query-loaders has the unlucky honour of
being one of the few programs that invokes the pseudo syscall()
wrapper before any other functions that pseudo wraps and the missing
initializer made it explode?

>
> Cheers,
>
> Richard
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] autoconf-archive: update to version to 2018.03.13

[Brad Bishop]

2016.09.16 -> 2018.03.13

License-Update: s/http/https/ in the license requires md5sum update.

Signed-off-by: Brad Bishop 
---
v2: Add License-Update tag to commit message.
---
 ...utoconf-archive_2016.09.16.bb => autoconf-archive_2018.03.13.bb} | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/autoconf-archive/{autoconf-archive_2016.09.16.bb 
=> autoconf-archive_2018.03.13.bb} (66%)

diff --git 
a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb 
b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb
similarity index 66%
rename from 
meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
rename to meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb
index 89d57ac079..7d62e52ab8 100644
--- a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
+++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb
@@ -2,12 +2,12 @@ SUMMARY = "a collection of freely re-usable Autoconf macros"
 HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/;
 SECTION = "devel"
 LICENSE = "GPL-3.0-with-autoconf-exception"
-LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+LIC_FILES_CHKSUM = "file://COPYING;md5=11cc2d3ee574f9d6b7ee797bdce4d423 \
 file://COPYING.EXCEPTION;md5=fdef168ebff3bc2f13664c365a5fb515"
 
 SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
-SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"
-SRC_URI[sha256sum] = 
"e8f2efd235f842bad2f6938bf4a72240a5e5fcd248e8444335e63beb60fabd82"
+SRC_URI[md5sum] = "46b13a5936372297b6d49980327a3c35"
+SRC_URI[sha256sum] = 
"6175f90d9fa64c4d939bdbb3e8511ae0ee2134863a2c7bf8d9733819efa6e159"
 
 inherit autotools allarch
 
-- 
2.14.3
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

[Bruce Ashfield]

On Sat, Mar 31, 2018 at 11:35 AM, Seebs  wrote:
> On Fri, 30 Mar 2018 23:02:29 -0700
> Andre McCurdy  wrote:
>
>> On Fri, Mar 30, 2018 at 10:06 PM, Seebs  wrote:
>> > That's the problem: There's no sane way to express "the size that
>> > you would have gotten for these arguments of unknown types"
>>
>> And there I think lies the key point that you still haven't grasped.
>
> I think you're right, but also you're being sorta rude about it. I

FWIW, I was thinking the same thing.

seebs is quite capable of working through this .. with all the bike shedding
here, it is taking up time that could actually be spent on the solution.

Cheers,

Bruce

> think you're missing the distinction between "broad enough experience
> with weird edge cases to be possibly-unduly cautious" and "has no idea
> which end of a compiler is up".
>
>> The arguments are not of unknown types - they are all of types which
>> are the same size as integer registers.
>
> It turns out, in C, "the same size" is *not enough information* to
> determine where an argument goes. It is probably enough information for
> the subset of arguments that syscall is using, on these architectures,
> but I say "probably" because I have no spec to point to that says it's
> necessarily the case.
>
>> The syscall manpage very
>> clearly documents the fact that all arguments to Linux syscalls are
>> passed to the kernel in registers. I think you even asked me why that
>> was important or useful.
>
> I'm still honestly not totally sure why it has to say *which*
> registers, specifically. Under what circumstances will my invocation of
> syscall(2) be changed by the knowledge that argument 5 to an OABI ARM
> system gets passed in v1? The information being present implies that I
> might need to know this to invoke syscall(2) correctly, but the only
> examples given are not actually specific to that information.
>
>> If there's any user space code out there which calls libc syscall()
>> and does not pass variables which libc syscall() (or a wrapper for it)
>> can unconditionally treat as a type which fits into integer registers
>> than it's a bug the caller. End of story.
>
> This raises an interesting point. The man page says that the dummy 0
> argument is needed for SYS_readahead because of an alignment issue, to
> force the value into r2/r3. It does not say that the manual split of the
> 64-bit value into two halves is needed, it just does that. Is that
> actually required anyway, or only because of the need to pad the
> argument list? (For instance, look at sync_file_range2(), which
> reorders the arguments to sync_file_range() for efficiency.
>
> ... Oh, wow. I went and checked on readahead():
>
>>> On some 32-bit architectures, the calling signature for this
>>> system call differs, for the reasons described in syscall(2).
>
> Note how they don't specify what the alternative calling signature is.
>
> -s
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

[Seebs]

On Sat, 31 Mar 2018 14:12:55 +0100
Richard Purdie  wrote:

> I believe that libglib-2.0 does use syscall() for something and that
> the above programs are calling into it and faulting.

Interesting! I'll poke around and see what I can find.

-s
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

[Seebs]

On Fri, 30 Mar 2018 23:02:29 -0700
Andre McCurdy  wrote:

> On Fri, Mar 30, 2018 at 10:06 PM, Seebs  wrote:
> > That's the problem: There's no sane way to express "the size that
> > you would have gotten for these arguments of unknown types"
> 
> And there I think lies the key point that you still haven't grasped.

I think you're right, but also you're being sorta rude about it. I
think you're missing the distinction between "broad enough experience
with weird edge cases to be possibly-unduly cautious" and "has no idea
which end of a compiler is up".

> The arguments are not of unknown types - they are all of types which
> are the same size as integer registers.

It turns out, in C, "the same size" is *not enough information* to
determine where an argument goes. It is probably enough information for
the subset of arguments that syscall is using, on these architectures,
but I say "probably" because I have no spec to point to that says it's
necessarily the case.

> The syscall manpage very
> clearly documents the fact that all arguments to Linux syscalls are
> passed to the kernel in registers. I think you even asked me why that
> was important or useful.

I'm still honestly not totally sure why it has to say *which*
registers, specifically. Under what circumstances will my invocation of
syscall(2) be changed by the knowledge that argument 5 to an OABI ARM
system gets passed in v1? The information being present implies that I
might need to know this to invoke syscall(2) correctly, but the only
examples given are not actually specific to that information.

> If there's any user space code out there which calls libc syscall()
> and does not pass variables which libc syscall() (or a wrapper for it)
> can unconditionally treat as a type which fits into integer registers
> than it's a bug the caller. End of story.

This raises an interesting point. The man page says that the dummy 0
argument is needed for SYS_readahead because of an alignment issue, to
force the value into r2/r3. It does not say that the manual split of the
64-bit value into two halves is needed, it just does that. Is that
actually required anyway, or only because of the need to pad the
argument list? (For instance, look at sync_file_range2(), which
reorders the arguments to sync_file_range() for efficiency.

... Oh, wow. I went and checked on readahead():

>> On some 32-bit architectures, the calling signature for this
>> system call differs, for the reasons described in syscall(2).

Note how they don't specify what the alternative calling signature is.

-s
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

[Richard Purdie]

Just to report back, I've tried testing an earlier version of pseudo
master with the path changes reverted and current master. With both I'm
seeing librsvg fail during do_install with a segfault (you have to
remove the 2> /dev/null to see it).

I'm seeing multiple entries in the host's dmesg:

[180364.269879] glib-compile-re[38258]: segfault at 0 ip   (null) sp 
7aafbf78 error 14 in glib-compile-resources[55abc201b000+9000]
[180376.499904] glib-compile-re[46860]: segfault at 0 ip   (null) sp 
7ffd3b10f2c8 error 14 in glib-compile-resources[55b2cb528000+9000]
[180376.612404] glib-compile-re[46862]: segfault at 0 ip   (null) sp 
7fff612977f8 error 14 in glib-compile-resources[55ad08797000+9000]
[180376.726317] glib-compile-re[46864]: segfault at 0 ip   (null) sp 
7ffdce018928 error 14 in glib-compile-resources[5610851ec000+9000]
[180376.836705] glib-compile-re[46866]: segfault at 0 ip   (null) sp 
7ffc586fdda8 error 14 in glib-compile-resources[562f38dfc000+9000]
[180603.294668] gdk-pixbuf-quer[51620]: segfault at 0 ip   (null) sp 
7ffce7947fe8 error 14 in gdk-pixbuf-query-loaders.real[55b88bb7f000+2000]
[185206.227285] gdk-pixbuf-quer[51885]: segfault at 0 ip   (null) sp 
7ffe6393ae28 error 14 in gdk-pixbuf-query-loaders.real[556db9ae3000+2000]
[186523.735264] gdk-pixbuf-quer[70272]: segfault at 0 ip   (null) sp 
7fff6a855808 error 14 in gdk-pixbuf-query-loaders.real[55ec4e8fd000+2000]

I believe that libglib-2.0 does use syscall() for something and that
the above programs are calling into it and faulting.

Its likely possible to reproduce this outside of a build by running
make install from librsvg under pseudo.

If I take master and revert 778abd3686fb7c419e9016fdd9e93819405d52aa fr
om pseudo, it no longer segfaults.

So something is not working correctly with the intercept sadly.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

[Andre McCurdy]

On Fri, Mar 30, 2018 at 10:06 PM, Seebs  wrote:
> That's the problem: There's no sane way to express "the size that you
> would have gotten for these arguments of unknown types"

And there I think lies the key point that you still haven't grasped.
The arguments are not of unknown types - they are all of types which
are the same size as integer registers. The syscall manpage very
clearly documents the fact that all arguments to Linux syscalls are
passed to the kernel in registers. I think you even asked me why that
was important or useful.

If there's any user space code out there which calls libc syscall()
and does not pass variables which libc syscall() (or a wrapper for it)
can unconditionally treat as a type which fits into integer registers
than it's a bug the caller. End of story.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core