[Mesa-dev] [PATCH 4/4] util/os_misc: os_get_available_system_memory() for OpenBSD

[Jonathan Gray]

Return the smallest value of available non-kernel physical memory and
the static per process data size limit as the amount of available
system memory on OpenBSD.

Signed-off-by: Jonathan Gray 
---
 src/util/os_misc.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/src/util/os_misc.c b/src/util/os_misc.c
index 581e15f3934..9b13dcdb9f8 100644
--- a/src/util/os_misc.c
+++ b/src/util/os_misc.c
@@ -28,6 +28,7 @@
 
 #include "os_misc.h"
 #include "os_file.h"
+#include "macros.h"
 
 #include 
 
@@ -57,6 +58,9 @@
 #  include 
 #elif DETECT_OS_LINUX || DETECT_OS_CYGWIN || DETECT_OS_SOLARIS || 
DETECT_OS_HURD
 #  include 
+#elif DETECT_OS_OPENBSD
+#  include 
+#  include 
 #elif DETECT_OS_APPLE || DETECT_OS_BSD
 #  include 
 #elif DETECT_OS_HAIKU
@@ -209,6 +213,22 @@ os_get_available_system_memory(uint64_t *size)
 
free(meminfo);
return false;
+#elif DETECT_OS_OPENBSD
+   struct rlimit rl;
+   int mib[] = { CTL_HW, HW_USERMEM64 };
+   int64_t mem_available;
+   size_t len = sizeof(mem_available);
+
+   /* physmem - wired */
+   if (sysctl(mib, 2, _available, , NULL, 0) == -1)
+  return false;
+
+   /* static login.conf limit */
+   if (getrlimit(RLIMIT_DATA, ) == -1)
+  return false;
+
+   *size = MIN2(mem_available, rl.rlim_cur);
+   return true;
 #else
return false;
 #endif
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] util/os_misc: add os_get_available_system_memory()

[Jonathan Gray]

Add os_get_available_system_memory() derived from
src/intel/vulkan/anv_device.c get_available_system_memory()

Signed-off-by: Jonathan Gray 
---
 src/util/os_misc.c | 31 +++
 src/util/os_misc.h |  6 ++
 2 files changed, 37 insertions(+)

diff --git a/src/util/os_misc.c b/src/util/os_misc.c
index e6894731b63..581e15f3934 100644
--- a/src/util/os_misc.c
+++ b/src/util/os_misc.c
@@ -27,6 +27,7 @@
 
 
 #include "os_misc.h"
+#include "os_file.h"
 
 #include 
 
@@ -44,6 +45,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #endif
 
@@ -182,3 +185,31 @@ os_get_total_physical_memory(uint64_t *size)
return false;
 #endif
 }
+
+bool
+os_get_available_system_memory(uint64_t *size)
+{
+#if DETECT_OS_LINUX
+   char *meminfo = os_read_file("/proc/meminfo");
+   if (!meminfo)
+  return false;
+
+   char *str = strstr(meminfo, "MemAvailable:");
+   if (!str) {
+  free(meminfo);
+  return false;
+   }
+
+   uint64_t kb_mem_available;
+   if (sscanf(str, "MemAvailable: %" PRIx64, _mem_available) == 1) {
+  free(meminfo);
+  *size = kb_mem_available << 10;
+  return true;
+   }
+
+   free(meminfo);
+   return false;
+#else
+   return false;
+#endif
+}
diff --git a/src/util/os_misc.h b/src/util/os_misc.h
index 19c8962d5d8..60811faf5a4 100644
--- a/src/util/os_misc.h
+++ b/src/util/os_misc.h
@@ -95,6 +95,12 @@ os_get_option(const char *name);
 bool
 os_get_total_physical_memory(uint64_t *size);
 
+/*
+ * Amount of physical memory available to a process
+ */
+bool
+os_get_available_system_memory(uint64_t *size);
+
 
 #ifdef __cplusplus
 }
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] anv: use os_get_available_system_memory()

[Jonathan Gray]

Replace local get_available_system_memory() function with
os_get_available_system_memory().

Signed-off-by: Jonathan Gray 
---
 src/intel/vulkan/anv_device.c | 30 --
 1 file changed, 4 insertions(+), 26 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index b9429ff611a..eec37bb8399 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -356,29 +356,6 @@ anv_physical_device_free_disk_cache(struct 
anv_physical_device *device)
 #endif
 }
 
-static uint64_t
-get_available_system_memory()
-{
-   char *meminfo = os_read_file("/proc/meminfo");
-   if (!meminfo)
-  return 0;
-
-   char *str = strstr(meminfo, "MemAvailable:");
-   if (!str) {
-  free(meminfo);
-  return 0;
-   }
-
-   uint64_t kb_mem_available;
-   if (sscanf(str, "MemAvailable: %" PRIx64, _mem_available) == 1) {
-  free(meminfo);
-  return kb_mem_available << 10;
-   }
-
-   free(meminfo);
-   return 0;
-}
-
 static VkResult
 anv_physical_device_init(struct anv_physical_device *device,
  struct anv_instance *instance,
@@ -510,7 +487,8 @@ anv_physical_device_init(struct anv_physical_device *device,
 */
device->has_bindless_samplers = device->info.gen >= 8;
 
-   device->has_mem_available = get_available_system_memory() != 0;
+   uint64_t avail_mem;
+   device->has_mem_available = os_get_available_system_memory(_mem);
 
device->always_flush_cache =
   driQueryOptionb(>dri_options, "always_flush_cache");
@@ -1918,8 +1896,8 @@ anv_get_memory_budget(VkPhysicalDevice physicalDevice,
   VkPhysicalDeviceMemoryBudgetPropertiesEXT *memoryBudget)
 {
ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
-   uint64_t sys_available = get_available_system_memory();
-   assert(sys_available > 0);
+   uint64_t sys_available;
+   assert(os_get_available_system_memory(_available));
 
VkDeviceSize total_heaps_size = 0;
for (size_t i = 0; i < device->memory.heap_count; i++)
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] anv: use os_get_total_physical_memory()

[Jonathan Gray]

Replace non-portable sysinfo() use with Mesa's
os_get_total_physical_memory()

Signed-off-by: Jonathan Gray 
---
 src/intel/vulkan/anv_device.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 0993a505075..b9429ff611a 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -37,6 +36,7 @@
 #include "util/disk_cache.h"
 #include "util/mesa-sha1.h"
 #include "util/os_file.h"
+#include "util/os_misc.h"
 #include "util/u_atomic.h"
 #include "util/u_string.h"
 #include "util/xmlpool.h"
@@ -101,10 +101,9 @@ static uint64_t
 anv_compute_heap_size(int fd, uint64_t gtt_size)
 {
/* Query the total ram from the system */
-   struct sysinfo info;
-   sysinfo();
-
-   uint64_t total_ram = (uint64_t)info.totalram * (uint64_t)info.mem_unit;
+   uint64_t total_ram;
+   if (!os_get_total_physical_memory(_ram))
+  return 0;
 
/* We don't want to burn too much ram with the GPU.  If the user has 4GiB
 * or less, we use at most half.  If they have more than 4GiB, we use 3/4.
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] CVE-2019-19520: Local privilege escalation via xlock

[Jonathan Gray]

On Thu, Dec 05, 2019 at 01:59:50PM +1000, Dave Airlie wrote:
> On Thu, 5 Dec 2019 at 13:42, Jonathan Gray  wrote:
> >
> > Until very recently OpenBSD built xlockmore against Mesa.  xlock is
> > setgid auth.  As described by Qualys in their advisory
> > https://marc.info/?l=oss-security=157549260013521=2
> > "CVE-2019-19520: Local privilege escalation via xlock"
> > the setuid check in the loader for LIBGL_DRIVERS_PATH does not handle
> > this.
> >
> Should we just use secure_getenv?
> 
> DAve.

That is also not portable, appears to be glibc only.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] CVE-2019-19520: Local privilege escalation via xlock

[Jonathan Gray]

Until very recently OpenBSD built xlockmore against Mesa.  xlock is
setgid auth.  As described by Qualys in their advisory
https://marc.info/?l=oss-security=157549260013521=2
"CVE-2019-19520: Local privilege escalation via xlock"
the setuid check in the loader for LIBGL_DRIVERS_PATH does not handle
this.

In OpenBSD we now build xlock with --without-opengl --without-mesa and
build Mesa with the following patch.  This is not an approach that would
work on linux and other systems without issetugid().
https://man.openbsd.org/issetugid.2
But it is worth bringing this issue to people's attention.

xenocara/lib/mesa/src/loader/loader.c
revision 1.8
date: 2019/12/04 02:26:36;  author: deraadt;  state: Exp;  lines: +2 -2;  
commitid: w6WeeZZ0y0WnF7VD;
Constrain honouring of path-related environment variables based upon
issetugid(), not just the sloppy uid != euid test. gid != egid cases
can occur also.
Part of 6.6/009_mesaxlock.patch.sig and 6.5/020_mesaxlock.patch.sig
From Qualys, ok

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 67cf92c19df..7865fe45c87 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -446,7 +446,7 @@ loader_get_driver_for_fd(int fd)
 * user's problem, but this allows vc4 simulator to run on an i965 host,
 * and may be useful for some touch testing of i915 on an i965 host.
 */
-   if (geteuid() == getuid()) {
+   if (issetugid() == 0 && geteuid() == getuid()) {
   driver = getenv("MESA_LOADER_DRIVER_OVERRIDE");
   if (driver)
  return strdup(driver);
@@ -534,7 +534,7 @@ loader_open_driver(const char *driver_name,
const struct __DRIextensionRec **(*get_extensions)(void);
 
search_paths = NULL;
-   if (geteuid() == getuid() && search_path_vars) {
+   if (issetugid() == 0 && geteuid() == getuid() && search_path_vars) {
   for (int i = 0; search_path_vars[i] != NULL; i++) {
  search_paths = getenv(search_path_vars[i]);
  if (search_paths)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util: unbreak endian detection on OpenBSD

[Jonathan Gray]

Since cbee1bfb34274668a05995b9d4c78ddec9e5ea4c endian.h is unconditionally
used if available.

glibc has byte order defines with two leading underscores.  OpenBSD
has private defines with a single leading underscore in machine/endian.h
and public defines in endian.h with no underscore.

The code under the endian.h block did not check if symbols were
defined before equating them so '#if __BYTE_ORDER == __LITTLE_ENDIAN'
would turn into '#if 0 == 0' which is always true.

Signed-off-by: Jonathan Gray 
Fixes: cbee1bfb342 ("meson/configure: detect endian.h instead of trying to 
guess when it's available")
---
 src/util/u_endian.h | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/util/u_endian.h b/src/util/u_endian.h
index 6bbae3c444c..3f76f340837 100644
--- a/src/util/u_endian.h
+++ b/src/util/u_endian.h
@@ -30,10 +30,20 @@
 #ifdef HAVE_ENDIAN_H
 #include 
 
-#if __BYTE_ORDER == __LITTLE_ENDIAN
+/* glibc */
+#if defined(__BYTE_ORDER) && (__BYTE_ORDER == __LITTLE_ENDIAN)
 # define UTIL_ARCH_LITTLE_ENDIAN 1
 # define UTIL_ARCH_BIG_ENDIAN 0
-#elif __BYTE_ORDER == __BIG_ENDIAN
+#elif defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)
+# define UTIL_ARCH_LITTLE_ENDIAN 0
+# define UTIL_ARCH_BIG_ENDIAN 1
+#endif
+
+/* OpenBSD */
+#if defined(BYTE_ORDER) && (BYTE_ORDER == LITTLE_ENDIAN)
+# define UTIL_ARCH_LITTLE_ENDIAN 1
+# define UTIL_ARCH_BIG_ENDIAN 0
+#elif defined(BYTE_ORDER) && (BYTE_ORDER == BIG_ENDIAN)
 # define UTIL_ARCH_LITTLE_ENDIAN 0
 # define UTIL_ARCH_BIG_ENDIAN 1
 #endif
@@ -60,8 +70,8 @@
 # define UTIL_ARCH_BIG_ENDIAN 1
 #endif
 
-#elif defined(__OpenBSD__) || defined(__NetBSD__) || \
-  defined(__FreeBSD__) || defined(__DragonFly__)
+#elif defined(__NetBSD__) || defined(__FreeBSD__) || \
+  defined(__DragonFly__)
 #include 
 #include 
 
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] anv: implement OpenBSD get_available_system_memory()

[Jonathan Gray]

On Sun, Dec 01, 2019 at 03:22:01AM +1100, Jonathan Gray wrote:
> On Sun, Dec 01, 2019 at 02:21:49AM +1100, Jonathan Gray wrote:
> > map linux /proc/meminfo "MemAvailable" to uvm free pages
> 
> On second thought HW_USERMEM64 may be a better fit here.
> 
> "The amount of available non-kernel memory in bytes"
> 
> Which ends up being physmem - uvmexp.wired (memory that can't be paged
> out) instead of the current amount of free memory.

Along the lines of this:

commit e9d96571d3670de169595c2009e7a49febd7cd2d
Author: Jonathan Gray 
Date:   Wed Nov 27 01:01:44 2019 +1100

anv: implement OpenBSD get_available_system_memory()

Determine a value for how much memory a process can allocate
without failing not exceeding amount of physical memory
available to userspace.

v2: use the smallest value of available non-kernel
physical memory and per process data size limit.

Signed-off-by: Jonathan Gray 

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 2a2041535c5..eddcf727f8a 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -28,6 +28,7 @@
 #ifdef __OpenBSD__
 #include 
 #include 
+#include 
 #else
 #include 
 #endif
@@ -369,6 +370,22 @@ anv_physical_device_free_disk_cache(struct 
anv_physical_device *device)
 static uint64_t
 get_available_system_memory()
 {
+#ifdef __OpenBSD__
+   struct rlimit rl;
+   int mib[] = { CTL_HW, HW_USERMEM64 };
+   int64_t mem_available;
+   size_t size = sizeof(mem_available);
+
+   /* physmem - wired */
+   if (sysctl(mib, 2, _available, , NULL, 0) == -1)
+  return 0;
+
+   /* fixed login.conf limit */
+   if (getrlimit(RLIMIT_DATA, ) == -1)
+  return 0;
+
+   return MIN2(mem_available, rl.rlim_cur);
+#else
char *meminfo = os_read_file("/proc/meminfo");
if (!meminfo)
   return 0;
@@ -387,6 +404,7 @@ get_available_system_memory()
 
free(meminfo);
return 0;
+#endif
 }
 
 static VkResult
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] anv: implement OpenBSD get_available_system_memory()

[Jonathan Gray]

On Sun, Dec 01, 2019 at 02:21:49AM +1100, Jonathan Gray wrote:
> map linux /proc/meminfo "MemAvailable" to uvm free pages

On second thought HW_USERMEM64 may be a better fit here.

"The amount of available non-kernel memory in bytes"

Which ends up being physmem - uvmexp.wired (memory that can't be paged
out) instead of the current amount of free memory.

> 
> Signed-off-by: Jonathan Gray 
> ---
>  src/intel/vulkan/anv_device.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 81e3905ae99..ce93718c106 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -370,6 +370,16 @@ anv_physical_device_free_disk_cache(struct 
> anv_physical_device *device)
>  static uint64_t
>  get_available_system_memory()
>  {
> +#ifdef __OpenBSD__
> +   int uvmexp_mib[] = { CTL_VM, VM_UVMEXP };
> +   struct uvmexp uvmexp;
> +   size_t size;
> +
> +   size = sizeof(uvmexp);
> +   if (sysctl(uvmexp_mib, 2, , , NULL, 0) == -1)
> +  return 0;
> +   return uvmexp.free * uvmexp.pagesize;
> +#else
> char *meminfo = os_read_file("/proc/meminfo");
> if (!meminfo)
>return 0;
> @@ -388,6 +398,7 @@ get_available_system_memory()
>  
> free(meminfo);
> return 0;
> +#endif
>  }
>  
>  static VkResult
> -- 
> 2.24.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] anv: implement OpenBSD get_available_system_memory()

[Jonathan Gray]

map linux /proc/meminfo "MemAvailable" to uvm free pages

Signed-off-by: Jonathan Gray 
---
 src/intel/vulkan/anv_device.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 81e3905ae99..ce93718c106 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -370,6 +370,16 @@ anv_physical_device_free_disk_cache(struct 
anv_physical_device *device)
 static uint64_t
 get_available_system_memory()
 {
+#ifdef __OpenBSD__
+   int uvmexp_mib[] = { CTL_VM, VM_UVMEXP };
+   struct uvmexp uvmexp;
+   size_t size;
+
+   size = sizeof(uvmexp);
+   if (sysctl(uvmexp_mib, 2, , , NULL, 0) == -1)
+  return 0;
+   return uvmexp.free * uvmexp.pagesize;
+#else
char *meminfo = os_read_file("/proc/meminfo");
if (!meminfo)
   return 0;
@@ -388,6 +398,7 @@ get_available_system_memory()
 
free(meminfo);
return 0;
+#endif
 }
 
 static VkResult
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] anv: get total system memory on OpenBSD

[Jonathan Gray]

Use sysctl to get total ram on OpenBSD where sysinfo() is not available.

Signed-off-by: Jonathan Gray 
---
 src/intel/vulkan/anv_device.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 250f75e9936..81e3905ae99 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -25,7 +25,12 @@
 #include 
 #include 
 #include 
+#ifdef __OpenBSD__
+#include 
+#include 
+#else
 #include 
+#endif
 #include 
 #include 
 #include 
@@ -97,10 +102,19 @@ static uint64_t
 anv_compute_heap_size(int fd, uint64_t gtt_size)
 {
/* Query the total ram from the system */
+#ifdef __OpenBSD__
+   int mib[] = { CTL_HW, HW_PHYSMEM64 };
+   int64_t total_ram;
+   size_t size = sizeof(total_ram);
+
+   if (sysctl(mib, 2, _ram, , NULL, 0) == -1)
+  return 0;
+#else
struct sysinfo info;
sysinfo();
 
uint64_t total_ram = (uint64_t)info.totalram * (uint64_t)info.mem_unit;
+#endif
 
/* We don't want to burn too much ram with the GPU.  If the user has 4GiB
 * or less, we use at most half.  If they have more than 4GiB, we use 3/4.
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util/futex: use futex syscall on OpenBSD

[Jonathan Gray]

Make use of the futex syscall added in OpenBSD 6.2.

Signed-off-by: Jonathan Gray 
---
 src/util/futex.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/src/util/futex.h b/src/util/futex.h
index 268af92882a..cf8dd0206c9 100644
--- a/src/util/futex.h
+++ b/src/util/futex.h
@@ -85,6 +85,24 @@ static inline int futex_wait(uint32_t *addr, int32_t value, 
struct timespec *tim
return _umtx_op(addr, UMTX_OP_WAIT_UINT, (uint32_t)value, uaddr, uaddr2) == 
-1 ? errno : 0;
 }
 
+#elif defined(__OpenBSD__)
+
+#include 
+#include 
+
+static inline int futex_wake(uint32_t *addr, int count)
+{
+   return futex(addr, FUTEX_WAKE, count, NULL, NULL);
+}
+
+static inline int futex_wait(uint32_t *addr, int32_t value, const struct 
timespec *timeout)
+{
+   struct timespec tsrel, tsnow;
+   clock_gettime(CLOCK_MONOTONIC, ); 
+   timespecsub(timeout, , );
+   return futex(addr, FUTEX_WAIT, value, , NULL);
+}
+
 #endif
 
 #endif /* UTIL_FUTEX_H */
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util/anon_file: add OpenBSD shm_mkstemp() path

[Jonathan Gray]

memfd_create() is a linux syscall replace the use of it with
shm_mkstemp() on OpenBSD.

unconditionally include stdlib.h for mkstemp()/mkostemp()

Signed-off-by: Jonathan Gray 
---
 src/util/anon_file.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/util/anon_file.c b/src/util/anon_file.c
index bd415adb647..6c8885707f4 100644
--- a/src/util/anon_file.c
+++ b/src/util/anon_file.c
@@ -33,16 +33,15 @@
 #include 
 #include 
 #include 
+#include 
 
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__OpenBSD__)
 #include 
 #elif defined(HAVE_MEMFD_CREATE) || defined(ANDROID)
 #include 
 #include 
-#include 
 #else
 #include 
-#include 
 #endif
 
 #if !(defined(__FreeBSD__) || defined(HAVE_MEMFD_CREATE) || 
defined(HAVE_MKOSTEMP) || defined(ANDROID))
@@ -119,6 +118,11 @@ os_create_anonymous_file(off_t size, const char 
*debug_name)
 #ifdef __FreeBSD__
(void*)debug_name;
fd = shm_open(SHM_ANON, O_CREAT | O_RDWR | O_CLOEXEC, 0600);
+#elif defined(__OpenBSD__)
+   char template[] = "/tmp/mesa-XX";
+   fd = shm_mkstemp(template);
+   if (fd != -1)
+  shm_unlink(template);
 #elif defined(HAVE_MEMFD_CREATE) || defined(ANDROID)
if (!debug_name)
   debug_name = "mesa-shared";
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util/u_thread: don't restrict u_thread_get_time_nano() to __linux__

[Jonathan Gray]

pthread_getcpuclockid() and clock_gettime() are also available on at least
OpenBSD, FreeBSD, NetBSD, DragonFly, Cygwin.

Signed-off-by: Jonathan Gray 
---
 src/util/u_thread.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/u_thread.h b/src/util/u_thread.h
index 6fc923c10e6..461d30bdd12 100644
--- a/src/util/u_thread.h
+++ b/src/util/u_thread.h
@@ -149,7 +149,7 @@ util_get_L3_for_pinned_thread(thrd_t thread, unsigned 
cores_per_L3)
 static inline int64_t
 u_thread_get_time_nano(thrd_t thread)
 {
-#if defined(__linux__) && defined(HAVE_PTHREAD)
+#if defined(HAVE_PTHREAD)
struct timespec ts;
clockid_t cid;
 
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: update Makefile.sources for perf changes

[Jonathan Gray]

brw_performance_query_metrics.h was removed in
134e750e16bfc53480e0bba6f0ae3e1d2a7fb87c and
brw_performance_query.h was removed in
8ae6667992ccca41d08884d863b8aeb22a4c4e65

remove reference to these files from Makefile.sources

Signed-off-by: Jonathan Gray 
Cc: 19.2 19.3 
---
 src/mesa/drivers/dri/i965/Makefile.sources | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index ed6b880bc20..469ee2f5d2d 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -35,9 +35,7 @@ i965_FILES = \
brw_object_purgeable.c \
brw_pipe_control.c \
brw_pipe_control.h \
-   brw_performance_query.h \
brw_performance_query.c \
-   brw_performance_query_metrics.h \
brw_program.c \
brw_program.h \
brw_program_binary.c \
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] winsys/amdgpu: avoid double simple_mtx_unlock()

[Jonathan Gray]

pthread_mutex_unlock() when unlocked is documented by posix as
being undefined behaviour.  On OpenBSD pthread_mutex_unlock() will call
abort(3) if this happens.

This occurs in amdgpu_winsys_create() after
cb446dc0fa5c68f681108f4613560543aa4cf553
winsys/amdgpu: Add amdgpu_screen_winsys

Signed-off-by: Jonathan Gray 
Cc: 19.2 19.3 
---
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
index a89432d8594..2fe227c9213 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
@@ -326,7 +326,6 @@ amdgpu_winsys_create(int fd, const struct 
pipe_screen_config *config,
aws = util_hash_table_get(dev_tab, dev);
if (aws) {
   pipe_reference(NULL, >reference);
-  simple_mtx_unlock(_tab_mutex);
 
   /* Release the device handle, because we don't need it anymore.
* This function is returning an existing winsys instance, which
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] mapi: avoid text relocation in x86 tsd stubs

[Jonathan Gray]

On Sun, Nov 11, 2018 at 03:47:35PM +1100, Jonathan Gray wrote:
> Make similiar changes to libglvnd to avoid a text relocation in
> x86 tsd stubs fixing the build with lld.
> 
> v2:
>   - store the address of the GOT in ebx required before calling PLT stub
>   - change .balign values to match X86_ENTRY_SIZE

When a different version of this patch was committed/pushed in
45206d7673adb1484cbdb3eadaf82e0849c9cdcf
(with author rewritten to imply I wrote the commit message)
it did not include the .balign changes to match the entry size change.

Was this purposefully skipped or overlooked as the bugzilla patch was
used?

The diff to what was committed and this patch is

diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
index bd8db7b19f9..1dec3ed86c4 100644
--- a/src/mapi/entry_x86_tsd.h
+++ b/src/mapi/entry_x86_tsd.h
@@ -34,18 +34,18 @@
 #define X86_ENTRY_SIZE 64
 
 __asm__(".text\n"
-".balign 32\n"
+".balign " U_STRINGIFY(X86_ENTRY_SIZE) "\n"
 "x86_entry_start:");
 
 #define STUB_ASM_ENTRY(func)\
".globl " func "\n"  \
".type " func ", @function\n"\
-   ".balign 32\n"   \
+   ".balign " U_STRINGIFY(X86_ENTRY_SIZE) "\n" \
func ":"
 
 #define STUB_ASM_CODE(slot) \
"push %ebx\n\t"  \
-   "call 1f\n\t"\
+   "call 1f\n"  \
"1:\n\t" \
"popl %ebx\n\t"  \
"addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx\n\t" \
@@ -53,7 +53,7 @@ __asm__(".text\n"
"mov (%eax), %eax\n\t"   \
"testl %eax, %eax\n\t"   \
"jne 1f\n\t" \
-   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
+   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n" \
"1:\n\t"     \
"pop %ebx\n\t"   \
"jmp *(4 * " slot ")(%eax)"
@@ -63,7 +63,7 @@ __asm__(".text\n"
 
 #ifndef MAPI_MODE_BRIDGE
 
-__asm__(".balign 32\n"
+__asm__(".balign " U_STRINGIFY(X86_ENTRY_SIZE) "\n"
 "x86_entry_end:");
 
 #include 

> 
> Signed-off-by: Jonathan Gray 
> Cc: mesa-sta...@lists.freedesktop.org
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108541
> ---
>  src/mapi/entry_x86_tsd.h | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
> index 0c28c8ff068..1dec3ed86c4 100644
> --- a/src/mapi/entry_x86_tsd.h
> +++ b/src/mapi/entry_x86_tsd.h
> @@ -31,25 +31,31 @@
>  #define HIDDEN
>  #endif
>  
> -#define X86_ENTRY_SIZE 32
> +#define X86_ENTRY_SIZE 64
>  
>  __asm__(".text\n"
> -".balign 32\n"
> +".balign " U_STRINGIFY(X86_ENTRY_SIZE) "\n"
>  "x86_entry_start:");
>  
>  #define STUB_ASM_ENTRY(func)\
> ".globl " func "\n"  \
> ".type " func ", @function\n"\
> -   ".balign 32\n"   \
> +   ".balign " U_STRINGIFY(X86_ENTRY_SIZE) "\n" \
> func ":"
>  
>  #define STUB_ASM_CODE(slot) \
> -   "movl " ENTRY_CURRENT_TABLE ", %eax\n\t" \
> +   "push %ebx\n\t"  \
> +   "call 1f\n"  \
> +   "1:\n\t" \
> +   "popl %ebx\n\t"  \
> +   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx\n\t" \
> +   "movl " ENTRY_CURRENT_TABLE "@GOT(%ebx), %eax\n\t" \
> +   "mov (%eax), %eax\n\t"   \
> "testl %eax, %eax\n\t"   \
> -   "je 1f\n\t"  \
> -   "jmp *(4 * " slot ")(%eax)\n"\
> +   "jne 1f\n\t" \
> +   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n" \
> "1:\n\t" \
> -   "call " ENTRY_CURRENT_TABLE_GET "\n\t" \
> +   "pop %ebx\n\t"   \
> "jmp *(4 * " slot ")(%eax)"
>  
>  #define MAPI_TMP_STUB_ASM_GCC
> @@ -57,7 +63,7 @@ __asm__(".text\n"
>  
>  #ifndef MAPI_MODE_BRIDGE
>  
> -__asm__(".balign 32\n"
> +__asm__(".balign " U_STRINGIFY(X86_ENTRY_SIZE) "\n"
>  "x86_entry_end:");
>  
>  #include 
> -- 
> 2.19.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Jonathan Gray]

Compared to linux and libdrm Mesa is missing a VLV and ICL id.

0x0f30
ff049b6ce21d2814451afd4a116d001712e0116b
drm/i915: bind driver to ValleyView chipsets

0x8A70
d55cb4fa2cf0105bfb16b60a2846737b91fdc173
drm/i915/icl: Add the ICL PCI IDs

The Intel Media SDK describes these as

/* VLV */
{ 0x0f30, MFX_HW_VLV, MFX_GT1 },   /* VLV mobile */

/* ICL LP */
{ 0x8A70, MFX_HW_ICL_LP, MFX_GT1 }

and libdrm's intel_chipset.h describes the VLV id as

#define PCI_CHIP_VALLEYVIEW_PO  0x0f30 /* VLV PO board */

It isn't clear what the ICL configuration should be from public
information.

diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index b91abd7a3f9..3568007b1ef 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -86,6 +86,7 @@ CHIPSET(0x0D2B, hsw_gt3, "Intel(R) Haswell")
 CHIPSET(0x0D0E, hsw_gt1, "Intel(R) Haswell")
 CHIPSET(0x0D1E, hsw_gt2, "Intel(R) Haswell")
 CHIPSET(0x0D2E, hsw_gt3, "Intel(R) Haswell")
+CHIPSET(0x0F30, byt, "Intel(R) Bay Trail")
 CHIPSET(0x0F31, byt, "Intel(R) Bay Trail")
 CHIPSET(0x0F32, byt, "Intel(R) Bay Trail")
 CHIPSET(0x0F33, byt, "Intel(R) Bay Trail")
@@ -212,4 +213,5 @@ CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice Lake 
6x8 GT1.5)")
 CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
 CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
 CHIPSET(0x8A5D, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
+CHIPSET(0x8A70, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
 CHIPSET(0x8A71, icl_1x8, "Intel(R) HD Graphics (Ice Lake 1x8 GT0.5)")
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Jonathan Gray]

On Thu, Jan 17, 2019 at 05:05:41PM -0500, Rob Clark wrote:
> On Thu, Jan 17, 2019 at 3:56 PM Jonathan Gray  wrote:
> >
> > On Mon, Jan 14, 2019 at 03:46:35PM +0200, Eero Tamminen wrote:
> > > Hi,
> > >
> > > On 13.1.2019 9.44, Jonathan Gray wrote:
> > > ...> As we can not depend on python to build Mesa in OpenBSD I will have 
> > > to
> > > > go back to maintaining a local Mesa build system if autotools is 
> > > > removed.
> > >
> > > Mesa already needs python-mako (for code generation) with Autotools.
> > > Why Meson also needing Python is a problem?
> >
> > Python generated files can be generated per release to not depend on
> > python at build time.
> >
> > All of the files generated by python used in a build of Mesa on OpenBSD are
> > already included in Mesa tarballs except for egd_tables.h
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=103911
> 
> is pre-generating the ninja build files that meson generates an
> option?  (I assume that the generated ninja ends up not being portable
> across different build environments, but maybe for OpenBSD the build
> environment is uniform enough??  idk, just a thought)

I suspect the build files meson/ninja generates would not be portable
across architectures with different toolchains but have not looked.

> 
> Anyways, a lot of other projects have been switching to meson, I guess
> OpenBSD will have to figure out how to deal getting python into build
> tree sooner or later, right?

OpenBSD is split into three repositories, src which contains the kernel,
libc, libssl, posix userland, toolchains (llvm, gcc, binutils) etc. 
xenocara which is the xserver, Mesa, xorg drivers, fonts etc and ports.

The src and xenocara trees are self contained and include all dependencies.
ports are makefiles which describe how to fetch sources and patches to
build binary packages.

meson is in ports and is used to build gnome and related parts but can
not be used in src or xenocara trees.  Python will not be imported into
src.  Either a c/perl implementation of meson is needed or a make based
build system from the OpenBSD perspective.

If Makefile.sources remains after autoconf goes I could use that as part
of a locally maintained not upstreamed make based build system.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Jonathan Gray]

On Mon, Jan 14, 2019 at 03:46:35PM +0200, Eero Tamminen wrote:
> Hi,
> 
> On 13.1.2019 9.44, Jonathan Gray wrote:
> ...> As we can not depend on python to build Mesa in OpenBSD I will have to
> > go back to maintaining a local Mesa build system if autotools is removed.
> 
> Mesa already needs python-mako (for code generation) with Autotools.
> Why Meson also needing Python is a problem?

Python generated files can be generated per release to not depend on
python at build time.

All of the files generated by python used in a build of Mesa on OpenBSD are
already included in Mesa tarballs except for egd_tables.h

https://bugs.freedesktop.org/show_bug.cgi?id=103911
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Jonathan Gray]

On Fri, Jan 11, 2019 at 02:11:28PM -0800, Matt Turner wrote:
> From: Gert Wollny 
> 
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
>   --enable-autotools
> 
> NAKed-by: Ilia Mirkin 
> Acked-by: Eric Engestrom 
> Acked-by: Kenneth Graunke 
> Acked-by: Lionel Landwerlin 
> Acked-by: Jason Ekstrand 
> Acked-by: Rob Clark 
> Acked-by: Marek Olk 
> Reviewed-by: Christian Gmeiner 
> Reviewed-by: Matt Turner 
> Reviewed-by: Eric Anholt 
> Signed-off-by: Gert Wollny 
> ---
> I think there's support for overriding the sole objection to this patch.
> 
> To confirm:
> 
> (1) The plan is to remove Autotools, perhaps after the 19.0 release
> 
> (2) This patch's purpose is to ensure that everyone knows that
> Autotools will be going away (think: people who build Mesa as
> part of an automated process and wouldn't notice a deprecation
>   warning unless it requires some action from them)
> 
> (3) We expect all reasonable concerns about Meson to be resolved
> before Autotools is removed (e.g., reconfiguration problems,
>   retrieving configuration command line, configuration status
>   output, etc.)

As we can not depend on python to build Mesa in OpenBSD I will have to
go back to maintaining a local Mesa build system if autotools is removed.

If you are looking for feedback from distributions you should also
mention this on the mesa-maintainers list.

> 
>  configure.ac | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index e4d20054d5f..c7473d77eff 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -52,6 +52,19 @@ mingw*)
>  ;;
>  esac
>  
> +AC_ARG_ENABLE(autotools,
> +   [AS_HELP_STRING([--enable-autotools],
> +   [Enable the use of this autotools based build 
> configuration])],
> +   [enable_autotools=$enableval], [enable_autotools=no])
> +
> +if test "x$enable_autotools" != "xyes" ; then
> +AC_MSG_ERROR([the autotools build system has been deprecated in favour of
> +meson and will be removed eventually. For instructions on how to use 
> meson
> +see https://www.mesa3d.org/meson.html.
> +If you still want to use the autotools build, then add --enable-autotools
> +to the configure command line.])
> +fi
> +
>  # Support silent build rules, requires at least automake-1.11. Disable
>  # by either passing --disable-silent-rules to configure or passing V=1
>  # to make
> -- 
> 2.19.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] mapi: avoid text relocation in x86 tsd stubs

[Jonathan Gray]

Make similiar changes to libglvnd to avoid a text relocation in
x86 tsd stubs fixing the build with lld.

v2:
  - store the address of the GOT in ebx required before calling PLT stub
  - change .balign values to match X86_ENTRY_SIZE

Signed-off-by: Jonathan Gray 
Cc: mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108541
---
 src/mapi/entry_x86_tsd.h | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
index 0c28c8ff068..1dec3ed86c4 100644
--- a/src/mapi/entry_x86_tsd.h
+++ b/src/mapi/entry_x86_tsd.h
@@ -31,25 +31,31 @@
 #define HIDDEN
 #endif
 
-#define X86_ENTRY_SIZE 32
+#define X86_ENTRY_SIZE 64
 
 __asm__(".text\n"
-".balign 32\n"
+".balign " U_STRINGIFY(X86_ENTRY_SIZE) "\n"
 "x86_entry_start:");
 
 #define STUB_ASM_ENTRY(func)\
".globl " func "\n"  \
".type " func ", @function\n"\
-   ".balign 32\n"   \
+   ".balign " U_STRINGIFY(X86_ENTRY_SIZE) "\n" \
func ":"
 
 #define STUB_ASM_CODE(slot) \
-   "movl " ENTRY_CURRENT_TABLE ", %eax\n\t" \
+   "push %ebx\n\t"  \
+   "call 1f\n"  \
+   "1:\n\t" \
+   "popl %ebx\n\t"  \
+   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx\n\t" \
+   "movl " ENTRY_CURRENT_TABLE "@GOT(%ebx), %eax\n\t" \
+   "mov (%eax), %eax\n\t"   \
"testl %eax, %eax\n\t"   \
-   "je 1f\n\t"  \
-   "jmp *(4 * " slot ")(%eax)\n"\
+   "jne 1f\n\t" \
+   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n" \
"1:\n\t" \
-   "call " ENTRY_CURRENT_TABLE_GET "\n\t" \
+   "pop %ebx\n\t"   \
"jmp *(4 * " slot ")(%eax)"
 
 #define MAPI_TMP_STUB_ASM_GCC
@@ -57,7 +63,7 @@ __asm__(".text\n"
 
 #ifndef MAPI_MODE_BRIDGE
 
-__asm__(".balign 32\n"
+__asm__(".balign " U_STRINGIFY(X86_ENTRY_SIZE) "\n"
 "x86_entry_end:");
 
 #include 
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] mapi: avoid text relocation in x86 tsd stubs

[Jonathan Gray]

On Fri, Nov 09, 2018 at 10:30:42PM +1100, Jonathan Gray wrote:
> On Thu, Nov 08, 2018 at 03:54:20PM +, Emil Velikov wrote:
> > On Fri, 2 Nov 2018 at 00:02, Jonathan Gray  wrote:
> > >
> > > On Thu, Nov 01, 2018 at 12:26:34PM -0700, Ian Romanick wrote:
> > > > On 10/31/2018 09:08 PM, Jonathan Gray wrote:
> > > > > Make similiar changes to libglvnd to avoid a text relocation in
> > > > > x86 tsd stubs fixing the build with lld.
> > > > >
> > > > > Signed-off-by: Jonathan Gray 
> > > > > Cc: mesa-sta...@lists.freedesktop.org
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108541
> > > > > ---
> > > > >  src/mapi/entry_x86_tsd.h | 14 +-
> > > > >  1 file changed, 9 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
> > > > > index 0c28c8ff068..e08a02f3db2 100644
> > > > > --- a/src/mapi/entry_x86_tsd.h
> > > > > +++ b/src/mapi/entry_x86_tsd.h
> > > > > @@ -31,7 +31,7 @@
> > > > >  #define HIDDEN
> > > > >  #endif
> > > > >
> > > > > -#define X86_ENTRY_SIZE 32
> > > > > +#define X86_ENTRY_SIZE 64
> > > > >
> > > > >  __asm__(".text\n"
> > > > >  ".balign 32\n"
> > > > > @@ -44,12 +44,16 @@ __asm__(".text\n"
> > > > > func ":"
> > > > >
> > > > >  #define STUB_ASM_CODE(slot) \
> > > > > -   "movl " ENTRY_CURRENT_TABLE ", %eax\n\t" \
> > > > > +   "call 1f\n\t"\
> > > > > +   "1:\n\t" \
> > > > > +   "popl %eax\n\t"  \
> > > > > +   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
> > > > > +   "movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
> > > > > +   "mov (%eax), %eax\n\t"   \
> > > > > "testl %eax, %eax\n\t"   \
> > > > > -   "je 1f\n\t"  \
> > > > > -   "jmp *(4 * " slot ")(%eax)\n"\
> > > > > +   "jne 1f\n\t" \
> > > > > +   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
> > > > > "1:\n\t" \
> > > > > -   "call " ENTRY_CURRENT_TABLE_GET "\n\t" \
> > > > > "jmp *(4 * " slot ")(%eax)"
> > > >
> > > > After this change, the code is:
> > > >
> > > > #define STUB_ASM_CODE(slot) \
> > > >"call 1f\n\t"\
> > > >"1:\n\t" \
> > > >"popl %eax\n\t"  \
> > > >"addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
> > > >"movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
> > > >"mov (%eax), %eax\n\t"   \
> > > >"testl %eax, %eax\n\t"   \
> > > >"jne 1f\n\t" \
> > > >"call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
> > > >"1:\n\t" \
> > > >"jmp *(4 * " slot ")(%eax)"
> > > >
> > > > So there's going to be two labels "1:".  Does that even assemble?
> > >
> > > Yes, the call/jmp is always forward as it is '1f'.
> > > This also runs glxinfo, glxgears etc on a pentium m running OpenBSD/i386.
> > >
> > > https://github.com/NVIDIA/libglvnd/blob/master/src/GLdispatch/vnd-glapi/entry_x86_tsd.c#L58
> > >
> > > libglvnd has two labels like this as well, the ebx use there isn't needed.
> > 
> > Hi all, did this get stuck or it's superseded/obsolete?
> 
> This is still the latest version of the patch.

The original patch should be ignored as while it worked for dynamically
linked libGL users like glxinfo and glxgears a program using SDL2 which
dlopens libGL segfaulted.  The ebx portion is required.

Index: entry_x86_tsd.h
===
RCS file: /cvs/xenocara/lib/mesa/src/mapi/entry_x86_tsd.h,v
retrieving revision 1.3
diff -u -p -r1.3 entry_x86_tsd.h
--- entry_x86_tsd.h 10 Nov 2018 08:11:16 -  1.3
+++ entry_x86_tsd.h 10 Nov 2018 08:12:09 -
@@ -31,7 +31,7 @@
 #define HIDDEN
 #endif
 
-#define X86_ENTRY_SIZE 32
+#define X86_ENTRY_SIZE 64
 
 __asm__(".text\n"
 ".balign 32\n"
@@ -44,12 +44,18 @@ __asm__(".text\n"
func ":"
 
 #define STUB_ASM_CODE(slot) \
-   "movl " ENTRY_CURRENT_TABLE ", %eax\n\t" \
+   "push %ebx\n\t"  \
+   "call 1f\n\t"\
+   "1:\n\t" \
+   "popl %ebx\n\t"  \
+   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx\n\t" \
+   "movl " ENTRY_CURRENT_TABLE "@GOT(%ebx), %eax\n\t" \
+   "mov (%eax), %eax\n\t"   \
"testl %eax, %eax\n\t"   \
-   "je 1f\n\t"  \
-   "jmp *(4 * " slot ")(%eax)\n"\
+   "jne 1f\n\t" \
+   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
"1:\n\t" \
-   "call " ENTRY_CURRENT_TABLE_GET "\n\t" \
+   "pop %ebx\n\t"   \
"jmp *(4 * " slot ")(%eax)"
 
 #define MAPI_TMP_STUB_ASM_GCC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] mapi: avoid text relocation in x86 tsd stubs

[Jonathan Gray]

On Thu, Nov 08, 2018 at 03:54:20PM +, Emil Velikov wrote:
> On Fri, 2 Nov 2018 at 00:02, Jonathan Gray  wrote:
> >
> > On Thu, Nov 01, 2018 at 12:26:34PM -0700, Ian Romanick wrote:
> > > On 10/31/2018 09:08 PM, Jonathan Gray wrote:
> > > > Make similiar changes to libglvnd to avoid a text relocation in
> > > > x86 tsd stubs fixing the build with lld.
> > > >
> > > > Signed-off-by: Jonathan Gray 
> > > > Cc: mesa-sta...@lists.freedesktop.org
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108541
> > > > ---
> > > >  src/mapi/entry_x86_tsd.h | 14 +-
> > > >  1 file changed, 9 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
> > > > index 0c28c8ff068..e08a02f3db2 100644
> > > > --- a/src/mapi/entry_x86_tsd.h
> > > > +++ b/src/mapi/entry_x86_tsd.h
> > > > @@ -31,7 +31,7 @@
> > > >  #define HIDDEN
> > > >  #endif
> > > >
> > > > -#define X86_ENTRY_SIZE 32
> > > > +#define X86_ENTRY_SIZE 64
> > > >
> > > >  __asm__(".text\n"
> > > >  ".balign 32\n"
> > > > @@ -44,12 +44,16 @@ __asm__(".text\n"
> > > > func ":"
> > > >
> > > >  #define STUB_ASM_CODE(slot) \
> > > > -   "movl " ENTRY_CURRENT_TABLE ", %eax\n\t" \
> > > > +   "call 1f\n\t"\
> > > > +   "1:\n\t" \
> > > > +   "popl %eax\n\t"  \
> > > > +   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
> > > > +   "movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
> > > > +   "mov (%eax), %eax\n\t"   \
> > > > "testl %eax, %eax\n\t"   \
> > > > -   "je 1f\n\t"  \
> > > > -   "jmp *(4 * " slot ")(%eax)\n"\
> > > > +   "jne 1f\n\t" \
> > > > +   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
> > > > "1:\n\t" \
> > > > -   "call " ENTRY_CURRENT_TABLE_GET "\n\t" \
> > > > "jmp *(4 * " slot ")(%eax)"
> > >
> > > After this change, the code is:
> > >
> > > #define STUB_ASM_CODE(slot) \
> > >"call 1f\n\t"\
> > >"1:\n\t" \
> > >"popl %eax\n\t"  \
> > >"addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
> > >"movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
> > >"mov (%eax), %eax\n\t"   \
> > >"testl %eax, %eax\n\t"   \
> > >"jne 1f\n\t" \
> > >"call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
> > >"1:\n\t" \
> > >"jmp *(4 * " slot ")(%eax)"
> > >
> > > So there's going to be two labels "1:".  Does that even assemble?
> >
> > Yes, the call/jmp is always forward as it is '1f'.
> > This also runs glxinfo, glxgears etc on a pentium m running OpenBSD/i386.
> >
> > https://github.com/NVIDIA/libglvnd/blob/master/src/GLdispatch/vnd-glapi/entry_x86_tsd.c#L58
> >
> > libglvnd has two labels like this as well, the ebx use there isn't needed.
> 
> Hi all, did this get stuck or it's superseded/obsolete?

This is still the latest version of the patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] mapi: avoid text relocation in x86 tsd stubs

[Jonathan Gray]

On Thu, Nov 01, 2018 at 12:26:34PM -0700, Ian Romanick wrote:
> On 10/31/2018 09:08 PM, Jonathan Gray wrote:
> > Make similiar changes to libglvnd to avoid a text relocation in
> > x86 tsd stubs fixing the build with lld.
> > 
> > Signed-off-by: Jonathan Gray 
> > Cc: mesa-sta...@lists.freedesktop.org
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108541
> > ---
> >  src/mapi/entry_x86_tsd.h | 14 +-
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
> > index 0c28c8ff068..e08a02f3db2 100644
> > --- a/src/mapi/entry_x86_tsd.h
> > +++ b/src/mapi/entry_x86_tsd.h
> > @@ -31,7 +31,7 @@
> >  #define HIDDEN
> >  #endif
> >  
> > -#define X86_ENTRY_SIZE 32
> > +#define X86_ENTRY_SIZE 64
> >  
> >  __asm__(".text\n"
> >  ".balign 32\n"
> > @@ -44,12 +44,16 @@ __asm__(".text\n"
> > func ":"
> >  
> >  #define STUB_ASM_CODE(slot) \
> > -   "movl " ENTRY_CURRENT_TABLE ", %eax\n\t" \
> > +   "call 1f\n\t"\
> > +   "1:\n\t" \
> > +   "popl %eax\n\t"  \
> > +   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
> > +   "movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
> > +   "mov (%eax), %eax\n\t"   \
> > "testl %eax, %eax\n\t"   \
> > -   "je 1f\n\t"  \
> > -   "jmp *(4 * " slot ")(%eax)\n"\
> > +   "jne 1f\n\t" \
> > +   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
> > "1:\n\t" \
> > -   "call " ENTRY_CURRENT_TABLE_GET "\n\t" \
> > "jmp *(4 * " slot ")(%eax)"
> 
> After this change, the code is:
> 
> #define STUB_ASM_CODE(slot) \
>"call 1f\n\t"\
>"1:\n\t" \
>"popl %eax\n\t"  \
>"addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
>"movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
>"mov (%eax), %eax\n\t"   \
>"testl %eax, %eax\n\t"   \
>"jne 1f\n\t" \
>"call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
>"1:\n\t" \
>"jmp *(4 * " slot ")(%eax)"
> 
> So there's going to be two labels "1:".  Does that even assemble?

Yes, the call/jmp is always forward as it is '1f'.
This also runs glxinfo, glxgears etc on a pentium m running OpenBSD/i386.

https://github.com/NVIDIA/libglvnd/blob/master/src/GLdispatch/vnd-glapi/entry_x86_tsd.c#L58

libglvnd has two labels like this as well, the ebx use there isn't needed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel/aubinator_error_decode: link libm

[Jonathan Gray]

Yes, that looks like the way to go.

On Thu, Nov 01, 2018 at 09:22:35AM +0200, Sergii Romantsov wrote:
> Hello, it looks like not complete fix.
> In my opinion issue is that libmesautil requires -lm than any library that
> uses libmesautil will not have such issue.
> Patch: https://patchwork.freedesktop.org/patch/259176/
> 
> On Thu, Nov 1, 2018 at 6:12 AM Jonathan Gray  wrote:
> 
> > aubinator_error_decode needs to link libm to build on OpenBSD/i386
> > ../../src/util/.libs/libmesautil.a(libmesautil_la-half_float.o): In
> > function `_mesa_float_to_half':
> > half_float.c:(.text+0x91): undefined reference to `lrintf'
> > half_float.c:(.text+0xc1): undefined reference to `lrintf'
> >
> > Signed-off-by: Jonathan Gray 
> > Cc: mesa-sta...@lists.freedesktop.org
> > ---
> >  src/intel/Makefile.tools.am | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/Makefile.tools.am b/src/intel/Makefile.tools.am
> > index 4809962b188..da49d37a728 100644
> > --- a/src/intel/Makefile.tools.am
> > +++ b/src/intel/Makefile.tools.am
> > @@ -61,7 +61,8 @@ tools_aubinator_error_decode_LDADD = \
> > isl/libisl.la \
> > $(top_builddir)/src/util/libmesautil.la \
> > $(PTHREAD_LIBS) \
> > -   $(ZLIB_LIBS)
> > +   $(ZLIB_LIBS) \
> > +   -lm
> >
> >  tools_aubinator_error_decode_CFLAGS = \
> > $(AM_CFLAGS) \
> > --
> > 2.19.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> 
> 
> -- 
> Sergii Romantsov
> GlobalLogic Inc.
> www.globallogic.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mapi: avoid text relocation in x86 tsd stubs

[Jonathan Gray]

Make similiar changes to libglvnd to avoid a text relocation in
x86 tsd stubs fixing the build with lld.

Signed-off-by: Jonathan Gray 
Cc: mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108541
---
 src/mapi/entry_x86_tsd.h | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
index 0c28c8ff068..e08a02f3db2 100644
--- a/src/mapi/entry_x86_tsd.h
+++ b/src/mapi/entry_x86_tsd.h
@@ -31,7 +31,7 @@
 #define HIDDEN
 #endif
 
-#define X86_ENTRY_SIZE 32
+#define X86_ENTRY_SIZE 64
 
 __asm__(".text\n"
 ".balign 32\n"
@@ -44,12 +44,16 @@ __asm__(".text\n"
func ":"
 
 #define STUB_ASM_CODE(slot) \
-   "movl " ENTRY_CURRENT_TABLE ", %eax\n\t" \
+   "call 1f\n\t"\
+   "1:\n\t" \
+   "popl %eax\n\t"  \
+   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
+   "movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
+   "mov (%eax), %eax\n\t"   \
"testl %eax, %eax\n\t"   \
-   "je 1f\n\t"  \
-   "jmp *(4 * " slot ")(%eax)\n"\
+   "jne 1f\n\t" \
+   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
"1:\n\t" \
-   "call " ENTRY_CURRENT_TABLE_GET "\n\t" \
"jmp *(4 * " slot ")(%eax)"
 
 #define MAPI_TMP_STUB_ASM_GCC
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel/tools: include stdarg.h in error2aub

[Jonathan Gray]

Include stdarg.h in error2aub.c otherwise it fails to build on
OpenBSD due to not finding definitions for va_list va_start va_end.

Signed-off-by: Jonathan Gray 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/tools/error2aub.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
index 8a23d5ef1e7..b6e056cbcde 100644
--- a/src/intel/tools/error2aub.c
+++ b/src/intel/tools/error2aub.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "aub_write.h"
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel/aubinator_error_decode: link libm

[Jonathan Gray]

aubinator_error_decode needs to link libm to build on OpenBSD/i386
../../src/util/.libs/libmesautil.a(libmesautil_la-half_float.o): In function 
`_mesa_float_to_half':
half_float.c:(.text+0x91): undefined reference to `lrintf'
half_float.c:(.text+0xc1): undefined reference to `lrintf'

Signed-off-by: Jonathan Gray 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/Makefile.tools.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/Makefile.tools.am b/src/intel/Makefile.tools.am
index 4809962b188..da49d37a728 100644
--- a/src/intel/Makefile.tools.am
+++ b/src/intel/Makefile.tools.am
@@ -61,7 +61,8 @@ tools_aubinator_error_decode_LDADD = \
isl/libisl.la \
$(top_builddir)/src/util/libmesautil.la \
$(PTHREAD_LIBS) \
-   $(ZLIB_LIBS)
+   $(ZLIB_LIBS) \
+   -lm
 
 tools_aubinator_error_decode_CFLAGS = \
$(AM_CFLAGS) \
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util/xmlpool: avoid using a GNU make pattern rule

[Jonathan Gray]

% pattern rules are a GNU extension.  Convert the use of one to a
inference rule to allow this to build on OpenBSD.

Signed-off-by: Jonathan Gray 
---
 src/util/xmlpool/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/xmlpool/Makefile.am b/src/util/xmlpool/Makefile.am
index 2b01391401b..5078f917948 100644
--- a/src/util/xmlpool/Makefile.am
+++ b/src/util/xmlpool/Makefile.am
@@ -82,7 +82,7 @@ options.h: t_options.h $(MOS)
--languages $(LANGS)
 
 # Update .mo files from the corresponding .po files.
-%.gmo: %.po
+.po.gmo:
@mo="$@"; \
lang=$${mo%%/*}; \
echo "Updating ($$lang) $@ from $?."; \
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] u_endian: use non-underscore-prefixed BYTE_ORDER names

[Jonathan Gray]

What happened with this patch?  It seems the problem it is fixing got
cherry-picked into 17.3 but the fix for master (and now 17.3) is still
not merged?

On Wed, Mar 28, 2018 at 06:05:12PM +0100, Eric Engestrom wrote:
> Cc: Jonathan Gray <j...@jsg.id.au>
> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> ---
> Note: scons was already defining _DEFAULT_SOURCE
> ---
>  Android.common.mk   | 2 +-
>  configure.ac| 2 +-
>  meson.build | 1 +
>  src/util/u_endian.h | 8 ++--
>  4 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/Android.common.mk b/Android.common.mk
> index e8aed48c31ab1704cbcf..74d1c2bf47920da53cb5 100644
> --- a/Android.common.mk
> +++ b/Android.common.mk
> @@ -22,7 +22,7 @@
>  # DEALINGS IN THE SOFTWARE.
>  
>  ifeq ($(LOCAL_IS_HOST_MODULE),true)
> -LOCAL_CFLAGS += -D_GNU_SOURCE
> +LOCAL_CFLAGS += -D_GNU_SOURCE -D_DEFAULT_SOURCE
>  endif
>  
>  LOCAL_C_INCLUDES += \
> diff --git a/configure.ac b/configure.ac
> index 99805e0f2bfd380fae4f..3618bc2ae259174b4f42 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -283,7 +283,7 @@ case "$host_os" in
>  android=yes
>  ;;
>  linux*|*-gnu*|gnu*|cygwin*)
> -DEFINES="$DEFINES -D_GNU_SOURCE"
> +DEFINES="$DEFINES -D_GNU_SOURCE -D_DEFAULT_SOURCE"
>  ;;
>  solaris*)
>  DEFINES="$DEFINES -DSVR4"
> diff --git a/meson.build b/meson.build
> index 31907b06fe5d32782da5..098722d09d8b6738645e 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -747,6 +747,7 @@ endif
>  # TODO: this is very incomplete
>  if ['linux', 'cygwin'].contains(host_machine.system())
>pre_args += '-D_GNU_SOURCE'
> +  pre_args += '-D_DEFAULT_SOURCE'
>  endif
>  
>  # Check for generic C arguments
> diff --git a/src/util/u_endian.h b/src/util/u_endian.h
> index e11b381588dbc960e8c3..c40293e6e3c6ff8479ac 100644
> --- a/src/util/u_endian.h
> +++ b/src/util/u_endian.h
> @@ -30,9 +30,13 @@
>  #ifdef HAVE_ENDIAN_H
>  #include 
>  
> -#if __BYTE_ORDER == __LITTLE_ENDIAN
> +#ifndef BYTE_ORDER
> +#error "BYTE_ORDER undefined"
> +#endif
> +
> +#if BYTE_ORDER == LITTLE_ENDIAN
>  # define PIPE_ARCH_LITTLE_ENDIAN
> -#elif __BYTE_ORDER == __BIG_ENDIAN
> +#elif BYTE_ORDER == BIG_ENDIAN
>  # define PIPE_ARCH_BIG_ENDIAN
>  #endif
>  
> -- 
> Cheers,
>   Eric
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] meson/configure: detect endian.h instead of trying to guess when it's available

[Jonathan Gray]

On Tue, Mar 27, 2018 at 07:36:17PM +0100, Emil Velikov wrote:
> On 25 March 2018 at 09:06, Jonathan Gray <j...@jsg.id.au> wrote:
> > On Wed, Mar 21, 2018 at 05:09:17PM +, Eric Engestrom wrote:
> >> Cc: Maxin B. John <maxin.j...@gmail.com>
> >> Cc: Khem Raj <raj.k...@gmail.com>
> >> Suggested-by: Jon Turney <jon.tur...@dronecode.org.uk>
> >> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> >> ---
> >>  configure.ac| 1 +
> >>  meson.build | 2 +-
> >>  src/util/u_endian.h | 2 +-
> >>  3 files changed, 3 insertions(+), 2 deletions(-)
> >
> > OpenBSD and I suspect other systems have an endian.h that does not have
> > the __ defines like glibc.
> >
> Sigh, I guess the C/POSIX commitee should really wake up and add that
> to the standard.
> ... one way or another.
> 
> Jonathan can you play around with AC_CHECK_DECLS and send a patch that
> works on your end?
> 
> Thanks
> Emil
> 
> [1] 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.62/html_node/Generic-Declarations.html

Or just change the header?

Some care is needed as '#if undefined == undefined' becomes '#if 0 == 0'
which is true...

diff --git a/src/util/u_endian.h b/src/util/u_endian.h
index e11b381588..bf3b8707a1 100644
--- a/src/util/u_endian.h
+++ b/src/util/u_endian.h
@@ -30,9 +30,17 @@
 #ifdef HAVE_ENDIAN_H
 #include 
 
-#if __BYTE_ORDER == __LITTLE_ENDIAN
+/* glibc */
+#if defined(__BYTE_ORDER) && (__BYTE_ORDER == __LITTLE_ENDIAN)
 # define PIPE_ARCH_LITTLE_ENDIAN
-#elif __BYTE_ORDER == __BIG_ENDIAN
+#elif defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)
+# define PIPE_ARCH_BIG_ENDIAN
+#endif
+
+/* OpenBSD */
+#if defined(BYTE_ORDER) && (BYTE_ORDER == LITTLE_ENDIAN)
+# define PIPE_ARCH_LITTLE_ENDIAN
+#elif defined(BYTE_ORDER) && (BYTE_ORDER == BIG_ENDIAN)
 # define PIPE_ARCH_BIG_ENDIAN
 #endif
 
@@ -54,8 +62,8 @@
 # define PIPE_ARCH_BIG_ENDIAN
 #endif
 
-#elif defined(__OpenBSD__) || defined(__NetBSD__) || \
-  defined(__FreeBSD__) || defined(__DragonFly__)
+#elif defined(__NetBSD__) || defined(__FreeBSD__) || \
+  defined(__DragonFly__)
 #include 
 #include 
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] meson/configure: detect endian.h instead of trying to guess when it's available

[Jonathan Gray]

On Wed, Mar 21, 2018 at 05:09:17PM +, Eric Engestrom wrote:
> Cc: Maxin B. John 
> Cc: Khem Raj 
> Suggested-by: Jon Turney 
> Signed-off-by: Eric Engestrom 
> ---
>  configure.ac| 1 +
>  meson.build | 2 +-
>  src/util/u_endian.h | 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)

OpenBSD and I suspect other systems have an endian.h that does not have
the __ defines like glibc.

So this change will break things unless a block along the lines of

#if _BYTE_ORDER == _LITTLE_ENDIAN
# define PIPE_ARCH_LITTLE_ENDIAN
#elif _BYTE_ORDER == _BIG_ENDIAN
# define PIPE_ARCH_BIG_ENDIAN
#endif

or

#if BYTE_ORDER == LITTLE_ENDIAN
# define PIPE_ARCH_LITTLE_ENDIAN
#elif BYTE_ORDER == BIG_ENDIAN
# define PIPE_ARCH_BIG_ENDIAN
#endif

is added.

 defines the public non underscored names
 will only pull in the underscored defines.

> 
> diff --git a/configure.ac b/configure.ac
> index 29d3c3457a7cdaefc36a..36c56da787e4fab5a355 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -865,6 +865,7 @@ fi
>  AC_HEADER_MAJOR
>  AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
>  AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
> +AC_CHECK_HEADER([endian.h], [DEFINES="$DEFINES -DHAVE_ENDIAN_H"])
>  AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
>  AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
>  AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
> diff --git a/meson.build b/meson.build
> index 88518ec0f0e9b81759a7..1132b4bd37075d8c9d21 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -904,7 +904,7 @@ elif cc.has_header_symbol('sys/mkdev.h', 'major')
>pre_args += '-DMAJOR_IN_MKDEV'
>  endif
>  
> -foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
> +foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h', 'endian.h']
>if cc.compiles('#include <@0@>'.format(h), name : '@0@ works'.format(h))
>  pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
>endif
> diff --git a/src/util/u_endian.h b/src/util/u_endian.h
> index 22d011ec0086ee77e11c..e11b381588dbc960e8c3 100644
> --- a/src/util/u_endian.h
> +++ b/src/util/u_endian.h
> @@ -27,7 +27,7 @@
>  #ifndef U_ENDIAN_H
>  #define U_ENDIAN_H
>  
> -#if defined(__GLIBC__) || defined(ANDROID) || defined(__CYGWIN__)
> +#ifdef HAVE_ENDIAN_H
>  #include 
>  
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
> -- 
> Cheers,
>   Eric
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] util: use clock_gettime() on PIPE_OS_BSD

[Jonathan Gray]

On Wed, Feb 28, 2018 at 08:22:57AM -0700, Brian Paul wrote:
> On 02/28/2018 03:19 AM, Jonathan Gray wrote:
> > OpenBSD, FreeBSD, NetBSD and DragonFlyBSD all have clock_gettime()
> > so use it when PIPE_OS_BSD is defined.
> > 
> > Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> > ---
> >   src/util/os_time.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/util/os_time.c b/src/util/os_time.c
> > index 72dc7e49c0..ac488b2287 100644
> > --- a/src/util/os_time.c
> > +++ b/src/util/os_time.c
> > @@ -55,7 +55,7 @@
> >   int64_t
> >   os_time_get_nano(void)
> >   {
> > -#if defined(PIPE_OS_LINUX)
> > +#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD)
> >  struct timespec tv;
> >  clock_gettime(CLOCK_MONOTONIC, );
> > 
> 
> LGTM.
> Reviewed-by: Brian Paul <bri...@vmware.com>

Thanks, there is also u_thread_get_time_nano().  I tried having autoconf
do AC_CHECK_FUNC for pthread_getcpuclockid() and setting a define
if it was found but couldn't seem to get the pthread linkage in the test
to work properly.  So for now in my local tree I have the diff below.

pthread_getcpuclockid() is available on
OpenBSD https://man.openbsd.org/pthread_getcpuclockid
FreeBSD https://www.freebsd.org/cgi/man.cgi?query=pthread_getcpuclockid
NetBSD 
http://netbsd.gw.com/cgi-bin/man-cgi?pthread_getcpuclockid++NetBSD-current
DragonFly 
https://leaf.dragonflybsd.org/cgi/web-man?command=pthread_getcpuclockid=ANY
Cygwin https://cygwin.com/cygwin-api/compatibility.html#std-susv4

but not macos and solaris?

diff --git a/src/util/u_thread.h b/src/util/u_thread.h
index 8c6e0bdc59..4f559e5c8f 100644
--- a/src/util/u_thread.h
+++ b/src/util/u_thread.h
@@ -71,21 +71,21 @@ static inline void u_thread_setname( const char *name )
 }
 
 /*
  * Thread statistics.
  */
 
 /* Return the time of a thread's CPU time clock. */
 static inline int64_t
 u_thread_get_time_nano(thrd_t thread)
 {
-#if defined(__linux__) && defined(HAVE_PTHREAD)
+#if defined(HAVE_PTHREAD)
struct timespec ts;
clockid_t cid;
 
pthread_getcpuclockid(thread, );
clock_gettime(cid, );
return (int64_t)ts.tv_sec * 10 + ts.tv_nsec;
 #else
return 0;
 #endif
 }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/util: use sockets on PIPE_OS_UNIX in u_network

[Jonathan Gray]

Instead of listing all the UNIX PIPE_OS platforms just use
PIPE_OS_UNIX.  Makes BSD sockets available on PIPE_OS_BSD.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/gallium/auxiliary/util/u_network.c | 9 +++--
 src/gallium/auxiliary/util/u_network.h | 5 +
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_network.c 
b/src/gallium/auxiliary/util/u_network.c
index 203205dc62..e74293bb10 100644
--- a/src/gallium/auxiliary/util/u_network.c
+++ b/src/gallium/auxiliary/util/u_network.c
@@ -9,8 +9,7 @@
 #  include 
 #  include 
 #  include 
-#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || \
-   defined(PIPE_OS_APPLE) || defined(PIPE_OS_CYGWIN) || 
defined(PIPE_OS_SOLARIS)
+#elif defined(PIPE_OS_UNIX)
 #  include 
 #  include 
 #  include 
@@ -58,8 +57,7 @@ u_socket_close(int s)
if (s < 0)
   return;
 
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) \
-|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_SOLARIS)
+#if defined(PIPE_OS_UNIX)
shutdown(s, SHUT_RDWR);
close(s);
 #elif defined(PIPE_SUBSYSTEM_WINDOWS_USER)
@@ -181,8 +179,7 @@ u_socket_listen_on_port(uint16_t portnum)
 void
 u_socket_block(int s, boolean block)
 {
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) \
-|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_SOLARIS)
+#if defined(PIPE_OS_UNIX)
int old = fcntl(s, F_GETFL, 0);
if (old == -1)
   return;
diff --git a/src/gallium/auxiliary/util/u_network.h 
b/src/gallium/auxiliary/util/u_network.h
index 61fe9a3c60..2b7ce3f4bd 100644
--- a/src/gallium/auxiliary/util/u_network.h
+++ b/src/gallium/auxiliary/util/u_network.h
@@ -4,10 +4,7 @@
 
 #include "pipe/p_compiler.h"
 
-#if defined(PIPE_SUBSYSTEM_WINDOWS_USER)
-#  define PIPE_HAVE_SOCKETS
-#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || \
-defined(PIPE_OS_APPLE) || defined(PIPE_OS_SOLARIS)
+#if defined(PIPE_SUBSYSTEM_WINDOWS_USER) || defined(PIPE_OS_UNIX)
 #  define PIPE_HAVE_SOCKETS
 #endif
 
-- 
2.16.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util: use clock_gettime() on PIPE_OS_BSD

[Jonathan Gray]

OpenBSD, FreeBSD, NetBSD and DragonFlyBSD all have clock_gettime()
so use it when PIPE_OS_BSD is defined.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/util/os_time.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/os_time.c b/src/util/os_time.c
index 72dc7e49c0..ac488b2287 100644
--- a/src/util/os_time.c
+++ b/src/util/os_time.c
@@ -55,7 +55,7 @@
 int64_t
 os_time_get_nano(void)
 {
-#if defined(PIPE_OS_LINUX)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD)
 
struct timespec tv;
clock_gettime(CLOCK_MONOTONIC, );
-- 
2.16.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/14] vc4, vc5: add ETIME fallback define

[Jonathan Gray]

On Fri, Jan 19, 2018 at 12:51:30AM +0300, Greg V wrote:
> On 01/18/2018 22:49, Dylan Baker wrote:
> > Quoting Emil Velikov (2018-01-18 10:40:40)
> > > On 18 January 2018 at 17:13, Dylan Baker  wrote:
> > > > I'm not sure how Emil feels about this (and the related patches) but I 
> > > > think it
> > > > might be better to handle this at the build system level, for meson it 
> > > > would
> > > > look something like (in the top level meson.build):
> > > > 
> > > > if cc.get_define('ETIME') == ''
> > > >pre_args += '-DETIME=ETIMEDOUT'
> > > > endif
> > > > 
> > > > Which should be a permanent fix. Emil can probably provide an autotools
> > > > equivalent.
> > > > 
> > > I'm not sure how the above works on meson - the define can come from
> > > multiple places.
> > > Surely meson does not check every header available on the system?
> > It doesn't, it checks for defines the preprocessor knows about, if you need 
> > to
> > check specific headers there's `has_header_symbol`.
> > 
> > Maybe this isn't feasible, but it really feels like having to define ETIME 
> > all
> > over the tree if it's not defined is fragile and ugly. I'm with you and Eric
> > that FreeBSD really should solve this themselves.
> Looks like OpenBSD and DragonFly don't define ETIME either, but NetBSD and
> illumos do.
> 
> BTW, Elf_Nhdr landed: 
> https://github.com/freebsd/freebsd/commit/f629be4b4612a8942dd5a2e7db8b68397d1186cd
> :)

ETIME is a STREAMS errno marked as optional and obsolete in POSIX.

"Strictly Conforming POSIX Applications and Strictly Conforming XSI
Applications shall not use obsolescent features."
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure.ac: pthread-stubs not present on OpenBSD

[Jonathan Gray]

pthread-stubs is no longer required on OpenBSD and has been removed.
libpthread parts involved moved to libc.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
Cc: 17.3 18.0 <mesa-sta...@lists.freedesktop.org>
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 89c5e74127..30a3377582 100644
--- a/configure.ac
+++ b/configure.ac
@@ -967,10 +967,10 @@ dnl In practise that should be sufficient for all 
platforms, since any
 dnl platforms build with GCC and Clang support the flag.
 PTHREAD_LIBS="$PTHREAD_LIBS -pthread"
 
-dnl pthread-stubs is mandatory on BSD platforms, due to the nature of the
+dnl pthread-stubs is mandatory on some BSD platforms, due to the nature of the
 dnl project. Even then there's a notable issue as described in the project 
README
 case "$host_os" in
-linux* | cygwin* | darwin* | solaris* | *-gnu* | gnu*)
+linux* | cygwin* | darwin* | solaris* | *-gnu* | gnu* | openbsd*)
 pthread_stubs_possible="no"
 ;;
 * )
-- 
2.16.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Android: define PIPE_OS_BSD

[Jonathan Gray]

On Wed, Jun 07, 2017 at 11:18:53PM +0800, Chih-Wei Huang wrote:
> 2017-06-07 22:47 GMT+08:00 Jonathan Gray <j...@jsg.id.au>:
> > On Wed, Jun 07, 2017 at 10:30:49PM +0800, Chih-Wei Huang wrote:
> >> 2017-06-07 21:54 GMT+08:00 Jonathan Gray <j...@jsg.id.au>:
> >> > On Wed, Jun 07, 2017 at 02:45:15PM +0100, Emil Velikov wrote:
> >> >> On 6 June 2017 at 07:30, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> >> >> >>> These are are due to program_invocation_short_name/getprogname. How
> >> >> >>> about updating the file alike xmlconfig.c?
> >> >> >>
> >> >> >> Oh... I didn't notice that.
> >> >> >> Let me check.
> >> >> >
> >> >> > Well, I saw several BSD OSes define
> >> >> > the same context:
> >> >> >
> >> >> > #elif defined(__NetBSD__) && defined(__NetBSD_Version__) &&
> >> >> > (__NetBSD_Version__ >= 106000100)
> >> >> > #include 
> >> >> > #define GET_PROGRAM_NAME() getprogname()
> >> >> > #elif defined(__DragonFly__)
> >> >> > #include 
> >> >> > #define GET_PROGRAM_NAME() getprogname()
> >> >> > #elif defined(__APPLE__)
> >> >> > #include 
> >> >> > #define GET_PROGRAM_NAME() getprogname()
> >> >> > #elif ...
> >> >> >
> >> >> > Not sure why has no OpenBSD?
> >> >> Your guess is as good as mine. Jonathan, any ideas if/who this is
> >> >> supposed to work for you guys?
> >> >
> >> > I have no idea where that block comes from as the latest
> >> > src/gallium/auxiliary/os/os_process.c
> >>
> >> Sorry. A little off-topic.
> >> Yes, the original patch is about os_process.c.
> >> But now we are talking about xmlconfig.c
> >> (in src/mesa/drivers/dri/common/ )
> >
> > You miss the other relevant part of that file
> >
> > #if !defined(GET_PROGRAM_NAME)
> > #if defined(__OpenBSD__) || defined(NetBSD) || defined(__UCLIBC__) || 
> > defined(ANDROID)
> > /* This is a hack. It's said to work on OpenBSD, NetBSD and GNU.
> >  * Rogelio M.Serrano Jr. reported it's also working with UCLIBC. It's
> >  * used as a last resort, if there is no documented facility available. */
> > static const char *__getProgramName () {
> > extern const char *__progname;
> > char * arg = strrchr(__progname, '/');
> > if (arg)
> > return arg+1;
> > else
> > return __progname;
> > }
> > #define GET_PROGRAM_NAME() __getProgramName()
> > #else
> > #define GET_PROGRAM_NAME() ""
> > #warning "Per application configuration won't work with your OS 
> > version."
> > #endif
> > #endif
> >
> > __progname exists since BSD 4.4,  OpenBSD has had getprogname() since
> > 5.4 in 2013.  This should all be simplified to look like or use the
> > gallium code.
> 
> No. I didn't miss the part.

__progname was never mentioned in any mail I read.

> That's exact what I asked.
> OpenBSD has getprogname().
> Why should it fall back to the hack?

Clearly the code is older than 2013.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Android: define PIPE_OS_BSD

[Jonathan Gray]

On Wed, Jun 07, 2017 at 10:30:49PM +0800, Chih-Wei Huang wrote:
> 2017-06-07 21:54 GMT+08:00 Jonathan Gray <j...@jsg.id.au>:
> > On Wed, Jun 07, 2017 at 02:45:15PM +0100, Emil Velikov wrote:
> >> On 6 June 2017 at 07:30, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> >> >>> These are are due to program_invocation_short_name/getprogname. How
> >> >>> about updating the file alike xmlconfig.c?
> >> >>
> >> >> Oh... I didn't notice that.
> >> >> Let me check.
> >> >
> >> > Well, I saw several BSD OSes define
> >> > the same context:
> >> >
> >> > #elif defined(__NetBSD__) && defined(__NetBSD_Version__) &&
> >> > (__NetBSD_Version__ >= 106000100)
> >> > #include 
> >> > #define GET_PROGRAM_NAME() getprogname()
> >> > #elif defined(__DragonFly__)
> >> > #include 
> >> > #define GET_PROGRAM_NAME() getprogname()
> >> > #elif defined(__APPLE__)
> >> > #include 
> >> > #define GET_PROGRAM_NAME() getprogname()
> >> > #elif ...
> >> >
> >> > Not sure why has no OpenBSD?
> >> Your guess is as good as mine. Jonathan, any ideas if/who this is
> >> supposed to work for you guys?
> >
> > I have no idea where that block comes from as the latest
> > src/gallium/auxiliary/os/os_process.c
> 
> Sorry. A little off-topic.
> Yes, the original patch is about os_process.c.
> But now we are talking about xmlconfig.c
> (in src/mesa/drivers/dri/common/ )

You miss the other relevant part of that file

#if !defined(GET_PROGRAM_NAME)
#if defined(__OpenBSD__) || defined(NetBSD) || defined(__UCLIBC__) || 
defined(ANDROID)
/* This is a hack. It's said to work on OpenBSD, NetBSD and GNU.
 * Rogelio M.Serrano Jr. reported it's also working with UCLIBC. It's
 * used as a last resort, if there is no documented facility available. */
static const char *__getProgramName () {
extern const char *__progname;
char * arg = strrchr(__progname, '/');
if (arg)
return arg+1;
else
return __progname;
}
#define GET_PROGRAM_NAME() __getProgramName()
#else
#define GET_PROGRAM_NAME() ""
#warning "Per application configuration won't work with your OS 
version."
#endif
#endif

__progname exists since BSD 4.4,  OpenBSD has had getprogname() since
5.4 in 2013.  This should all be simplified to look like or use the
gallium code.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Android: define PIPE_OS_BSD

[Jonathan Gray]

On Wed, Jun 07, 2017 at 02:45:15PM +0100, Emil Velikov wrote:
> On 6 June 2017 at 07:30, Chih-Wei Huang  wrote:
> > 2017-06-06 13:06 GMT+08:00 Chih-Wei Huang :
> >> 2017-06-05 21:04 GMT+08:00 Emil Velikov :
> >>> On 4 June 2017 at 04:31, Chih-Wei Huang  wrote:
>  Android bionic is derived from OpenBSD. So the logics of BSD
>  almost apply to Android as well.
> 
> >>> Having platform FOO define both PIPE_OS_BSD and PIPE_OS_LINUX does not
> >>> seem so obvious bth.
> >>
> >> Yeah.. but that's true.
> >> Android is a BSD-style userspace
> >> running on a Linux kernel.
> >>
>  It fixes the warnings
> 
>  external/mesa/src/gallium/auxiliary/os/os_process.c:43:2: warning: 
>  unexpected platform in os_process.c [-W#warnings]
>   ^
>  external/mesa/src/gallium/auxiliary/os/os_process.c:97:2: warning: 
>  unexpected platform in os_process.c [-W#warnings]
> >>>
> >>> These are are due to program_invocation_short_name/getprogname. How
> >>> about updating the file alike xmlconfig.c?
> >>
> >> Oh... I didn't notice that.
> >> Let me check.
> >
> > Well, I saw several BSD OSes define
> > the same context:
> >
> > #elif defined(__NetBSD__) && defined(__NetBSD_Version__) &&
> > (__NetBSD_Version__ >= 106000100)
> > #include 
> > #define GET_PROGRAM_NAME() getprogname()
> > #elif defined(__DragonFly__)
> > #include 
> > #define GET_PROGRAM_NAME() getprogname()
> > #elif defined(__APPLE__)
> > #include 
> > #define GET_PROGRAM_NAME() getprogname()
> > #elif ...
> >
> > Not sure why has no OpenBSD?
> Your guess is as good as mine. Jonathan, any ideas if/who this is
> supposed to work for you guys?

I have no idea where that block comes from as the latest
src/gallium/auxiliary/os/os_process.c
is still

#elif defined(__GLIBC__) || defined(__CYGWIN__)
  name = program_invocation_short_name;
#elif defined(PIPE_OS_BSD) || defined(PIPE_OS_APPLE)
  /* *BSD and OS X */
  name = getprogname();
#elif defined(PIPE_OS_HAIKU)
  image_info info;
  get_image_info(B_CURRENT_TEAM, );
  name = info.name;
#else
#warning unexpected platform in os_process.c
  return FALSE;
#endif

> 
> > Android definitely has getprogname().
> > (at least since Lollipop as I know)
> >
> > Should I add:
> >
> > #elif defined(__OpenBSD__) || defined(ANDROID)
> > #include 
> > #define GET_PROGRAM_NAME() getprogname()
> > #elif...
> >
> > I either don't understand why not all the BSD OSes
> > which has getprogname() share the same if case.
> >
> It should be doable but need a bit of cleanup:
>  - doubt we're can use GLIBC earlier than v2 // not BSD related
>  - the FreeBSD/NetBSD version checks could(?) be dropped
> For each case, please check (CC) some people using the respective platform.
> Mesa git log and the respective upstream repos should have contact points.
> 
> Thanks
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fix __atomic* builtins detection for Clang

[Jonathan Gray]

On Sat, May 13, 2017 at 09:01:49AM +0200, Jan Beich wrote:
> Jonathan Gray <j...@jsg.id.au> writes:
> 
> > On Sat, May 13, 2017 at 02:22:30AM +0200, Jan Beich wrote:
> >
> >> "int" isn't large enough and lack of builtins only manifests at link time.
> >> This was breaking build on FreeBSD 11.0 i386 with Clang 3.8.0.
> >> 
> >> glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function 
> >> `disk_cache_remove':
> >> disk_cache.c:(.text+0x763): undefined reference to `__atomic_fetch_add_8'
> >> glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function 
> >> `cache_put':
> >> disk_cache.c:(.text+0xabc): undefined reference to `__atomic_fetch_add_8'
> >> disk_cache.c:(.text+0xec1): undefined reference to `__atomic_fetch_add_8'
> >> c++: error: linker command failed with exit code 1 (use -v to see 
> >> invocation)
> >
> > You should be building with -march=i586 on i386 for CX8.
> 
> -march=i586 doesn't help. Dimitry, could this be a Clang bug?

As it is accepted by clang 4.0 on amd64 but not with -m32 looks like.

> 
> $ cat a.c
> #include 
> int main() {
> uint64_t n;
> return __atomic_load_n(, __ATOMIC_ACQUIRE);
> }
> 
> $ clang40 -m32 -march=i586 a.c
> /tmp/a-d984ec.o: In function `main':
> a.c:(.text+0x21): undefined reference to `__atomic_load_8'
> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> full build log: http://sprunge.us/LJdh
> 
> >
> > The diff is wrong as it will break other architectures, ie powerpc.
> 
> And it's not broken already? -latomic isn't passed anywhere.

It is broken for different reasons on platforms that aren't linux.

It used to be you could disable the building the shader cache and not
build the i965 driver to avoid 64 bit atomics in Mesa.  The situation
may have gotten worse in recent releases, not sure.  If you are using
a compiler with __sync but not __atomic builtins it seems to have
gotten worse.

> 
> >
> > commit a6a38a038bd62e6d9558905f00bef81b5e7e6fcc
> > Author: Grazvydas Ignotas <nota...@gmail.com>
> > Date:   Fri Mar 31 01:26:25 2017 +0300
> >
> > util/u_atomic: provide 64bit atomics where they're missing
> >
> > attempts to handle powerpc like situations, though not sync
> > builtins being missing entirely.
> >
> >> ---
> >>  configure.ac | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/configure.ac b/configure.ac
> >> index 957d15df8c..5b11941a0c 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -403,9 +403,10 @@ AM_CONDITIONAL([SSE41_SUPPORTED], [test 
> >> x$SSE41_SUPPORTED = x1])
> >>  AC_SUBST([SSE41_CFLAGS], $SSE41_CFLAGS)
> >>  
> >>  dnl Check for new-style atomic builtins
> >> -AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
> >> +AC_LINK_IFELSE([AC_LANG_SOURCE([[
> >> +#include 
> >>  int main() {
> >> -int n;
> >> +uint64_t n;
> >>  return __atomic_load_n(, __ATOMIC_ACQUIRE);
> >>  }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=1)
> >>  if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fix __atomic* builtins detection for Clang

[Jonathan Gray]

On Sat, May 13, 2017 at 02:22:30AM +0200, Jan Beich wrote:
> "int" isn't large enough and lack of builtins only manifests at link time.
> This was breaking build on FreeBSD 11.0 i386 with Clang 3.8.0.

You should be building with -march=i586 on i386 for CX8.

The diff is wrong as it will break other architectures, ie powerpc.

commit a6a38a038bd62e6d9558905f00bef81b5e7e6fcc
Author: Grazvydas Ignotas 
Date:   Fri Mar 31 01:26:25 2017 +0300

util/u_atomic: provide 64bit atomics where they're missing

attempts to handle powerpc like situations, though not sync
builtins being missing entirely.

> 
> glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function 
> `disk_cache_remove':
> disk_cache.c:(.text+0x763): undefined reference to `__atomic_fetch_add_8'
> glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function 
> `cache_put':
> disk_cache.c:(.text+0xabc): undefined reference to `__atomic_fetch_add_8'
> disk_cache.c:(.text+0xec1): undefined reference to `__atomic_fetch_add_8'
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> ---
>  configure.ac | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 957d15df8c..5b11941a0c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -403,9 +403,10 @@ AM_CONDITIONAL([SSE41_SUPPORTED], [test 
> x$SSE41_SUPPORTED = x1])
>  AC_SUBST([SSE41_CFLAGS], $SSE41_CFLAGS)
>  
>  dnl Check for new-style atomic builtins
> -AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
> +AC_LINK_IFELSE([AC_LANG_SOURCE([[
> +#include 
>  int main() {
> -int n;
> +uint64_t n;
>  return __atomic_load_n(, __ATOMIC_ACQUIRE);
>  }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=1)
>  if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] intel: genxml: fix out of tree builds

[Jonathan Gray]

On Fri, Mar 31, 2017 at 04:53:21PM +0100, Emil Velikov wrote:
> On 31 March 2017 at 16:33, Lionel Landwerlin
>  wrote:
> > On 31/03/17 16:21, Emil Velikov wrote:
> >>
> >> On 31 March 2017 at 14:40, Lionel Landwerlin
> >>  wrote:
> >>>
> >>> v2: use Emil's recommendation
> >>>  change rule to closer to genxml/genX_bits.h
> >>>
> >>> Signed-off-by: Lionel Landwerlin 
> >>> ---
> >>>   src/intel/Makefile.genxml.am | 4 ++--
> >>>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
> >>> index 05a12f8f77..e34536d37c 100644
> >>> --- a/src/intel/Makefile.genxml.am
> >>> +++ b/src/intel/Makefile.genxml.am
> >>> @@ -34,9 +34,9 @@ $(GENXML_GENERATED_PACK_FILES):
> >>> genxml/gen_pack_header.py
> >>>  $(MKDIR_GEN)
> >>>  $(PYTHON_GEN) $(srcdir)/genxml/gen_pack_header.py $< > $@ ||
> >>> ($(RM) $@; false)
> >>>
> >>> -genxml/genX_xml.h: $(GENXML_XML_FILES) genxml/gen_zipped_file.py
> >>> +genxml/genX_xml.h: genxml/gen_zipped_file.py $(GENXML_XML_FILES)
> >>>  $(MKDIR_GEN)
> >>> -   $(AM_V_GEN) $(PYTHON2) $(srcdir)/genxml/gen_zipped_file.py
> >>> $(GENXML_XML_FILES) > $@ || ($(RM) $@; false)
> >>> +   $(PYTHON_GEN) $< $(GENXML_XML_FILES:%=$(srcdir)/%) > $@ || ($(RM)
> >>> $@; false)
> >>>
> >> This is not what I recommended :-( If my suggestion is unclear or
> >> buggy please say so.
> >>
> >> -Emil
> >>
> > Replacing "$(srcdir)/genxml/gen_zipped_file.py" by "$<" isn't right?
> > I think that's the only difference from what was in your email.
> 
> Barring the genX_bits.h case, we expand the script name throughout mesa.
> This way you don't really care the way the dependencies are listed,
> whether a new one gets added, etc.
> 
> -Emil

genX_bits.h should not be used as an example.

It uses $< in a non-suffix rule, a GNU extension.
It uses addprefix a GNU builtin.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] util/u_atomic: provide 64bit atomics where they're missing

[Jonathan Gray]

On Wed, Mar 29, 2017 at 04:55:54PM -0700, Matt Turner wrote:
> On Wed, Mar 29, 2017 at 4:13 PM, Grazvydas Ignotas  wrote:
> > There are still some distributions trying to support unfortunate people
> > with old or exotic CPUs that don't have 64bit atomic operations. When
> > compiling for such a machine, gcc conveniently inserts a library call to
> > a helper, but it's implementation is missing and we get a linker error.
> > This allows us to provide our implementation, which is marked weak to
> > prefer a better implementation, should one exist.
> >
> > Cc: Matt Turner 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93089
> > Signed-off-by: Grazvydas Ignotas 
> > ---
> 
> Thanks, this is a really good idea.
> 
> >  configure.ac  | 12 
> >  src/util/Makefile.sources |  1 +
> >  src/util/u_atomic.c   | 71 
> > +++
> >  3 files changed, 84 insertions(+)
> >  create mode 100644 src/util/u_atomic.c
> >
> > diff --git a/configure.ac b/configure.ac
> > index ab9a91e..89b615b 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -413,10 +413,22 @@ int main() {
> >  if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
> >  DEFINES="$DEFINES -DUSE_GCC_ATOMIC_BUILTINS"
> >  fi
> >  AM_CONDITIONAL([GCC_ATOMIC_BUILTINS_SUPPORTED], [test 
> > x$GCC_ATOMIC_BUILTINS_SUPPORTED = x1])
> >
> > +dnl Check if host supports 64bit atomics
> > +dnl note that lack of support usually results in link (not compile) error
> > +AC_LINK_IFELSE([AC_LANG_SOURCE([[
> > +#include 
> > +uint64_t v;
> > +int main() {
> > +return __sync_add_and_fetch(, (uint64_t)1);
> > +}]])], GCC_64BIT_ATOMICS_SUPPORTED=1)
> > +if test "x$GCC_64BIT_ATOMICS_SUPPORTED" != x1; then
> > +DEFINES="$DEFINES -DMISSING_64BIT_ATOMICS"
> > +fi
> > +
> >  dnl Check for Endianness
> >  AC_C_BIGENDIAN(
> > little_endian=no,
> > little_endian=yes,
> > little_endian=no,
> > diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
> > index 8ee45d5..e905734 100644
> > --- a/src/util/Makefile.sources
> > +++ b/src/util/Makefile.sources
> > @@ -41,10 +41,11 @@ MESA_UTIL_FILES := \
> > string_to_uint_map.h \
> > strndup.h \
> > strtod.c \
> > strtod.h \
> > texcompress_rgtc_tmp.h \
> > +   u_atomic.c \
> > u_atomic.h \
> > u_endian.h \
> > u_queue.c \
> > u_queue.h \
> > u_string.h \
> > diff --git a/src/util/u_atomic.c b/src/util/u_atomic.c
> > new file mode 100644
> > index 000..77ef119
> > --- /dev/null
> > +++ b/src/util/u_atomic.c
> > @@ -0,0 +1,71 @@
> > +/*
> > + * Copyright ?? 2017 The Mesa Project
> 
> The Mesa Project isn't something that can hold copyright. Your name
> should be here.
> 
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software"),
> > + * to deal in the Software without restriction, including without 
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the 
> > next
> > + * paragraph) shall be included in all copies or substantial portions of 
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> > + * IN THE SOFTWARE.
> > + */
> > +
> > +#if defined(MISSING_64BIT_ATOMICS) && defined(HAVE_PTHREAD)
> > +
> > +#include 
> > +#include 
> > +
> > +#if defined(HAVE_FUNC_ATTRIBUTE_WEAK) && !defined(__CYGWIN__)
> > +#define WEAK __attribute__((weak))
> > +#else
> > +#define WEAK
> > +#endif
> > +
> > +static pthread_mutex_t sync_mutex = PTHREAD_MUTEX_INITIALIZER;
> > +
> > +WEAK uint64_t __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
> 
> Let's do BSD-style function declarations, with the qualifiers and
> return type on their own line.
> 
> With those two trivial things changed, this is
> 
> Reviewed-by: Matt Turner 
> 
> Grazvydas, if you have not already, please file a request for a
> Freedesktop account [1] [2] and let's get you commit access.
> 
> Jonathan, can you check whether this resolves the bug entirely? Or are
> there some other __sync functions we need to implement? I see
> 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Tue, Mar 21, 2017 at 04:00:37PM +1100, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
> > 
> > 
> > On 21/03/17 06:39, Emil Velikov wrote:
> > > On 20 March 2017 at 18:30, Matt Turner <matts...@gmail.com> wrote:
> > > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov 
> > > > <emil.l.veli...@gmail.com> wrote:
> > > > > Seems like we ended up all over the place, so let me try afresh.
> > > > > 
> > > > > Above all:
> > > > >  - Saying "I don't care" about your users is arrogant - let us _not_
> > > > > do that, please ?
> > > > 
> > > > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > > > arbitrary restrictions caused including Mesa in its core: 10+ year old
> > > > GCC,
> > > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> > > wasn't OpenBSD to blame here ;-)
> > 
> > Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
> > switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
> > 
> > Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> > rather not go through the upgrade hassle if I don't have to."
> > 
> > Followed by Jose "We're internally building and shipping Mesa compiled with
> > GCC 4.4 (more specifically 4.4.3).
> > 
> > It's fine if you require GCC 4.8 on automake, but please leave support
> > for GCC 4.4.x in SCons."
> > 
> > By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> > various features backported, from what I understand Mesa would not build on
> > a real GCC 4.2 release and we should not be using it as a min version. IMO
> > if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> > the min GCC version.
> > 
> > I believe Jonathan would like us to stick with 4.2 as min but is prepared to
> > deal with it if we move on.
> 
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
> 
> We have one platform using clang/lld now (arm64) and are likely to move
> others in future where possible.  libtool has to be patched and the Mesa
> configure script regenerated to make this work or Mesa won't build due
> to libtool.m4 looking for specific strings in ld -v produced by bfd
> binutils or gold...
> 
> And yes if you change the configure script to check for a newer version
> I'll revert it locally like I did with the zlib one.
> 
> As I get the impression no one cares about patches for older GCC I've
> not being sending them to the list, ie

And to be clear this is code in Mesa violating the C++ standard
according to clang++ --std=c++14 -pedantic.

compiler/brw_vec4_gs_visitor.cpp:589:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_POINTS] =_3DPRIM_POINTLIST,
   ^~
compiler/brw_vec4_gs_visitor.cpp:590:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINES] = _3DPRIM_LINELIST,
   ^
compiler/brw_vec4_gs_visitor.cpp:591:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINE_LOOP] = _3DPRIM_LINELOOP,
   ^
compiler/brw_vec4_gs_visitor.cpp:592:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINE_STRIP] = _3DPRIM_LINESTRIP,
   ^~~
compiler/brw_vec4_gs_visitor.cpp:593:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_TRIANGLES] = _3DPRIM_TRILIST,
   ^~~~
compiler/brw_vec4_gs_visitor.cpp:594:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_TRIANGLE_STRIP] = _3DPRIM_TRISTRIP,
   ^~
compiler/brw_vec4_gs_visitor.cpp:595:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_TRIANGLE_FAN] = _3DPRIM_TRIFAN,
   ^~
compiler/brw_vec4_gs_visitor.cpp:596:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_QUADS] = _3DPRIM_QUADLIST,
   ^
compiler/brw_vec4_gs_visitor.cpp:597:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_QUAD_STRIP] = _3DPRIM_QUADSTRIP,
   ^~~
compiler/brw_vec4_gs_visitor.cpp:598:4: warning: designated initializers are a 
C

Re: [Mesa-dev] [PATCH v2] util/rand_xor: seed with getentropy when available

[Jonathan Gray]

On Thu, Mar 23, 2017 at 03:24:16PM +1100, Jonathan Gray wrote:
> Instead of using using /dev/urandom on Linux and time(NULL) elsewhere
> for a seed first use getentropy() for systems that have a kernel
> interface to get a seed such as OpenBSD.  This interface is also
> present in other systems such as Solaris and even Linux with a recent
> version of glibc.
> 
> v2: check for/use the different header Solaris and glibc use
> 
> Signed-off-by: Jonathan Gray <j...@jsg.id.au>

Even just changing the original to have the following would be an
improvement.

diff --git a/src/util/rand_xor.c b/src/util/rand_xor.c
index de05fa64b3..9780907368 100644
--- a/src/util/rand_xor.c
+++ b/src/util/rand_xor.c
@@ -22,12 +22,9 @@
  *
  */
 
-#if defined(__linux__)
-#include 
+#include 
 #include 
-#else
 #include 
-#endif
 
 #include "rand_xor.h"
 
@@ -53,29 +50,34 @@ rand_xorshift128plus(uint64_t *seed)
 void
 s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed)
 {
+   time_t now;
+
if (!randomised_seed)
   goto fixed_seed;
 
-#if defined(__linux__)
int fd = open("/dev/urandom", O_RDONLY);
if (fd < 0)
-  goto fixed_seed;
+  goto time_seed;
 
size_t seed_size = sizeof(uint64_t) * 2;
if (read(fd, seed, seed_size) != seed_size) {
   close(fd);
-  goto fixed_seed;
+  goto time_seed;
}
 
close(fd);
return;
 
-#else
+time_seed:
+
+   now = time(NULL);
+   if (now == -1)
+  goto fixed_seed;
+
seed[0] = 0x3bffb83978e24f88;
-   seed[1] = time(NULL);
+   seed[1] = now;
 
return;
-#endif
 
 fixed_seed:
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] util/rand_xor: seed with getentropy when available

[Jonathan Gray]

On Thu, Mar 23, 2017 at 03:24:16PM +1100, Jonathan Gray wrote:
> Instead of using using /dev/urandom on Linux and time(NULL) elsewhere
> for a seed first use getentropy() for systems that have a kernel
> interface to get a seed such as OpenBSD.  This interface is also
> present in other systems such as Solaris and even Linux with a recent
> version of glibc.
> 
> v2: check for/use the different header Solaris and glibc use
> 
> Signed-off-by: Jonathan Gray <j...@jsg.id.au>

The functions should really be split for random and deterministic
as well, but that is hard to cleanup without being able to assume
arc4random or equivalent is present.

diff --git a/configure.ac b/configure.ac
index c27646ca4c..a1a62482d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -792,6 +792,9 @@ AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES 
-DHAVE_POSIX_MEMALIGN"])
 dnl See if getentropy is available
 AC_CHECK_FUNC([getentropy], [DEFINES="$DEFINES -DHAVE_GETENTROPY"])
 
+dnl See if arc4random_buf is available
+AC_CHECK_FUNC([arc4random_buf], [DEFINES="$DEFINES -DHAVE_ARC4RANDOM_BUF"])
+
 dnl Check for zlib
 PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
 
diff --git a/src/gallium/drivers/radeon/r600_test_dma.c 
b/src/gallium/drivers/radeon/r600_test_dma.c
index 3c23b09329..0cdd24d1c0 100644
--- a/src/gallium/drivers/radeon/r600_test_dma.c
+++ b/src/gallium/drivers/radeon/r600_test_dma.c
@@ -77,7 +77,7 @@ static void set_random_pixels(struct pipe_context *ctx,
 
for (x = 0; x < size; x++) {
*ptr++ = *ptr_cpu++ =
-   
rand_xorshift128plus(seed_xorshift128plus);
+   
rand_xorshift128plus_deterministic(seed_xorshift128plus);
}
}
}
diff --git a/src/util/rand_xor.c b/src/util/rand_xor.c
index c613371f67..db642dae54 100644
--- a/src/util/rand_xor.c
+++ b/src/util/rand_xor.c
@@ -37,6 +37,10 @@
 #include 
 #endif
 
+#ifdef HAVE_ARC4RANDOM_BUF
+#include 
+#endif
+
 #include "rand_xor.h"
 
 /* Super fast random number generator.
@@ -45,7 +49,7 @@
  * to the public domain.
  */
 uint64_t
-rand_xorshift128plus(uint64_t *seed)
+rand_xorshift128plus_deterministic(uint64_t *seed)
 {
uint64_t *s = seed;
 
@@ -58,6 +62,18 @@ rand_xorshift128plus(uint64_t *seed)
return s[1] + s0;
 }
 
+uint64_t
+rand_xorshift128plus(uint64_t *seed)
+{
+#ifdef HAVE_ARC4RANDOM_BUF
+  uint64_t buf;
+  arc4random_buf(, sizeof(buf));
+  return buf;
+#else
+  return rand_xorshift128plus_deterministic(seed);
+#endif
+}
+
 void
 s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed)
 {
diff --git a/src/util/rand_xor.h b/src/util/rand_xor.h
index 532d549bcd..0fbf4d3a8a 100644
--- a/src/util/rand_xor.h
+++ b/src/util/rand_xor.h
@@ -31,6 +31,9 @@
 uint64_t
 rand_xorshift128plus(uint64_t *seed);
 
+uint64_t
+rand_xorshift128plus_deterministic(uint64_t *seed);
+
 void
 s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed);
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] util/rand_xor: seed with getentropy when available

[Jonathan Gray]

Instead of using using /dev/urandom on Linux and time(NULL) elsewhere
for a seed first use getentropy() for systems that have a kernel
interface to get a seed such as OpenBSD.  This interface is also
present in other systems such as Solaris and even Linux with a recent
version of glibc.

v2: check for/use the different header Solaris and glibc use

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 configure.ac|  4 
 src/util/rand_xor.c | 17 +++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index bc9c304c8d..c27646ca4c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -756,6 +756,7 @@ fi
 AC_HEADER_MAJOR
 AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
 AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
+AC_CHECK_HEADER([sys/random.h], [DEFINES="$DEFINES -DHAVE_SYS_RANDOM_H"])
 AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
 AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
 
@@ -788,6 +789,9 @@ esac
 dnl See if posix_memalign is available
 AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
 
+dnl See if getentropy is available
+AC_CHECK_FUNC([getentropy], [DEFINES="$DEFINES -DHAVE_GETENTROPY"])
+
 dnl Check for zlib
 PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
 
diff --git a/src/util/rand_xor.c b/src/util/rand_xor.c
index de05fa64b3..c613371f67 100644
--- a/src/util/rand_xor.c
+++ b/src/util/rand_xor.c
@@ -22,7 +22,15 @@
  *
  */
 
-#if defined(__linux__)
+#ifdef HAVE_GETENTROPY
+
+#ifdef HAVE_SYS_RANDOM_H
+#include 
+#else
+#include 
+#endif
+
+#elif defined(__linux__)
 #include 
 #include 
 #else
@@ -56,7 +64,12 @@ s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed)
if (!randomised_seed)
   goto fixed_seed;
 
-#if defined(__linux__)
+#ifdef HAVE_GETENTROPY
+   size_t seed_size = sizeof(uint64_t) * 2;
+   if (getentropy(seed, seed_size) == -1)
+  goto fixed_seed;
+   return;
+#elif defined(__linux__)
int fd = open("/dev/urandom", O_RDONLY);
if (fd < 0)
   goto fixed_seed;
-- 
2.12.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util/rand_xor: seed with getentropy when available

[Jonathan Gray]

Instead of using using /dev/urandom on Linux and time(NULL) elsewhere
for a seed first use getentropy() for systems that have a kernel
interface to get a seed such as OpenBSD.  This interface is also
present in other systems such as Solaris and even Linux with a recent
version of glibc.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 configure.ac|  3 +++
 src/util/rand_xor.c | 11 +--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index bc9c304c8d..1a2f58feaf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -788,6 +788,9 @@ esac
 dnl See if posix_memalign is available
 AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
 
+dnl See if getentropy is available
+AC_CHECK_FUNC([getentropy], [DEFINES="$DEFINES -DHAVE_GETENTROPY"])
+
 dnl Check for zlib
 PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
 
diff --git a/src/util/rand_xor.c b/src/util/rand_xor.c
index de05fa64b3..b71492b8fd 100644
--- a/src/util/rand_xor.c
+++ b/src/util/rand_xor.c
@@ -22,7 +22,9 @@
  *
  */
 
-#if defined(__linux__)
+#ifdef HAVE_GETENTROPY
+#include 
+#elif defined(__linux__)
 #include 
 #include 
 #else
@@ -56,7 +58,12 @@ s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed)
if (!randomised_seed)
   goto fixed_seed;
 
-#if defined(__linux__)
+#ifdef HAVE_GETENTROPY
+   size_t seed_size = sizeof(uint64_t) * 2;
+   if (getentropy(seed, seed_size) == -1)
+  goto fixed_seed;
+   return;
+#elif defined(__linux__)
int fd = open("/dev/urandom", O_RDONLY);
if (fd < 0)
   goto fixed_seed;
-- 
2.12.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> > I guess I'm a little late to the party here, but I haven't had time to
> > really let all of this sink in and actually look at meson.  It doesn't
> > seem so bad with a quick look and I think I could probably sort it out
> > when the time came, but there would still be a bit of a learning
> > curve.  While that may not be a big deal at the micro level, I have
> > concerns at the macro level.
> >
> > First, I'm concerned it may discourage casual developers and
> > packagers.  autotools isn't great, but most people are familiar enough
> > with it that they can get by.  Most people have enough knowledge of
> > autotools that they can pretty easily diagnose a configuration based
> > failure. There are a lot of resources for autotools.  I'm not sure
> > that would be the case for meson.  Do we as a community feel we have
> > enough meson experience to get people over the hump?  Anything that
> > makes it harder for someone to try a new build or do a bisect is a big
> > problem in my opinion.
> 
> One of the things that's prompted this on our side (I've talked this over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right. Emil almost always finds cases were 
> we've
> done things *almost*, but not quite right.
> 
> For my part, it took me about 3 or 4 days of reading through the docs and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic. 
> 
> > Next, my bigger concern is for distro and casual packagers and people
> > that maintain large build systems with lots of existing custom
> > configurations.  Changing from autotools would basically require many
> > of these existing tools and systems to be rewritten and then deal with
> > the debugging and fall out from that.  The potential decreased build
> > time is a nice bonus, but frankly a lot of people/companies have years
> > of investment in existing tools.
> 
> Sure, but we're also not the only ones investigating meson. Gnome is using it
> already, libepoxy is using it, gstreamer is using it. There are patches for
> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), 
> there
> are some other projects in the graphics sphere that people are working on. So
> even if we as a community decide that meson isn't for us, it's not going away.

It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.

> 
> Quoting Rob Clark (2017-03-22 10:07:54)
> > I guess an interesting question (from someone who doesn't know meson
> > yet) would be whether meson could slurp in the Makefile.sources type
> > stuff that we have, which are shared so far between
> > android/scons/autotools (and for the most part, kept developers from
> > having to care *too* much about the different build systems)
> 
> Jason and I have talked about that too. I'd suggested that we could write a
> module for meson to read makefile.sources (since we're surely not the only
> project that would benefit from such a module), except that android is moving 
> to
> blueprint[1] instead of android.mk files. As far as I can tell blueprint 
> doesn't
> support using makefile.sources, so it seems somewhat moot in a world of
> blueprint for android, meson for *.
> 
> I don't think that meson should try to generate blueprint files, since 
> blueprint
> is itself a metabuild system that generates ninja files, and is self
> boot-strapping Go code. I don't know if the community is going to want 
> blueprint
> to live in repo either, since one actually writes Go code for the build 
> system.
> (I'm not objecting prematurely, I'm just pointing out that the design is
> significantly different the Android.mk, and the community will probably want 
> to
> re-evaluate)
> 
> If android doesn't mandate a migration to blueprint, or blueprint does handle
> makefile.sources (I don't think it does), I'd be happy to propose a module for
> meson that could read makefile.sources, and write said module, and get said
> module upstream.
> 
> [1] https://godoc.org/github.com/google/blueprint
> > 
> > If so, that makes it easier to coexist with existing build systems.  I
> > don't think it would be a good idea to remove the autotools build
> > anytime soon.. that should be the last one removed, after meson has
> > replaced scons (and hopefully android?)
> 
> I would imagine that if we did merge meson, we would make at the very least 
> one
> release with meson and autotools (scons is VMWare's thing, they can migrate at
> their leisure), if not two, to 

Re: [Mesa-dev] [PATCH V2 2/3] util/rand_xor: add function to seed rand

[Jonathan Gray]

If a proper PRNG like arc4random backed by a syscall like getentropy
were used this would already handle reseeding on fork and fd exhaustion.

And look people have already gone out of their way to provide fallbacks
for these interfaces.

https://github.com/libressl-portable/openbsd/tree/master/src/lib/libcrypto/arc4random

On Wed, Mar 22, 2017 at 10:59:47AM +1100, Timothy Arceri wrote:
> V2: pass the seed to the seed function so that we can isolate
> its uses. Stop leaking fd when urandom couldn't be read.
> ---
>  src/gallium/drivers/radeon/r600_test_dma.c |  3 +-
>  src/util/rand_xor.c| 57 
> ++
>  src/util/rand_xor.h|  4 +++
>  3 files changed, 62 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeon/r600_test_dma.c 
> b/src/gallium/drivers/radeon/r600_test_dma.c
> index 8b4149a..3c23b09 100644
> --- a/src/gallium/drivers/radeon/r600_test_dma.c
> +++ b/src/gallium/drivers/radeon/r600_test_dma.c
> @@ -176,22 +176,21 @@ void r600_test_dma(struct r600_common_screen *rscreen)
>  
>   max_levels = screen->get_param(screen, PIPE_CAP_MAX_TEXTURE_2D_LEVELS);
>   max_tex_side = 1 << (max_levels - 1);
>  
>   /* Max 128 MB allowed for both textures. */
>   max_alloc_size = 128 * 1024 * 1024;
>  
>   /* the seed for random test parameters */
>   srand(0x9b47d95b);
>   /* the seed for random pixel data */
> - seed_xorshift128plus[0] = 0x3bffb83978e24f88;
> - seed_xorshift128plus[1] = 0x9238d5d56c71cd35;
> + s_rand_xorshift128plus(seed_xorshift128plus, false);
>  
>   iterations = 10; /* just kill it when you are bored */
>   num_partial_copies = 30;
>  
>   /* These parameters are randomly generated per test:
>* - whether to do one whole-surface copy or N partial copies per test
>* - which tiling modes to use (LINEAR_ALIGNED, 1D, 2D)
>* - which texture dimensions to use
>* - whether to use VRAM (all tiling modes) and GTT (staging, linear
>*   only) allocations
> diff --git a/src/util/rand_xor.c b/src/util/rand_xor.c
> index 07b4c22..ee506a2 100644
> --- a/src/util/rand_xor.c
> +++ b/src/util/rand_xor.c
> @@ -1,20 +1,77 @@
> +/*
> + * Copyright 2017 Timothy Arceri
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
> THE
> + * SOFTWARE.
> + *
> + */
> +
> +#if defined(__linux__)
> +#include 
> +#include 
> +#endif
> +
>  #include "rand_xor.h"
>  
>  /* Super fast random number generator.
>   *
>   * This rand_xorshift128plus function by Sebastiano Vigna belongs
>   * to the public domain.
>   */
>  uint64_t
>  rand_xorshift128plus(uint64_t *seed)
>  {
> uint64_t *s = seed;
>  
> uint64_t s1 = s[0];
> const uint64_t s0 = s[1];
> s[0] = s0;
> s1 ^= s1 << 23;
> s[1] = s1 ^ s0 ^ (s1 >> 18) ^ (s0 >> 5);
>  
> return s[1] + s0;
>  }
> +
> +void
> +s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed)
> +{
> +#if defined(__linux__)
> +   if (!randomised_seed)
> +  goto fixed_seed;
> +
> +   int fd = open("/dev/urandom", O_RDONLY);
> +   if (fd < 0)
> +  goto fixed_seed;
> +
> +   size_t seed_size = sizeof(uint64_t) * 2;
> +   if (read(fd, seed, seed_size) != seed_size) {
> +  close(fd);
> +  goto fixed_seed;
> +   }
> +
> +   close(fd);
> +   return;
> +
> +fixed_seed:
> +#endif
> +
> +   /* Fallback to a fixed seed */
> +   seed[0] = 0x3bffb83978e24f88;
> +   seed[1] = 0x9238d5d56c71cd35;
> +}
> diff --git a/src/util/rand_xor.h b/src/util/rand_xor.h
> index d5144e9..532d549 100644
> --- a/src/util/rand_xor.h
> +++ b/src/util/rand_xor.h
> @@ -19,15 +19,19 @@
>   * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
>   * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
> THE
>   * SOFTWARE.
>   *
>   */
>  
>  #ifndef RAND_XOR_H
>  #define 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Tue, Mar 21, 2017 at 09:22:50AM -0700, Dylan Baker wrote:
> Quoting Jani Nikula (2017-03-21 07:44:55)
> > On Thu, 16 Mar 2017, Dylan Baker  wrote:
> > > First it's written in python, [...]
> > 
> > How does meson handle python 2 vs. 3? How do you avoid issues in the
> > build files wrt this? On Debian meson seems to depend on python 3, so
> > are they fully python 3?
> 
> Meson requires python 3.4+, and doesn't support python 2. Python 3.4 was
> released in 2012. It's also worth nothing that a couple of us have been 
> working
> to get mesa's python scripts python3 compatible, so in the (hopefully) near
> future python2 wouldn't be required.

Mesa only requires python for development versions not to build
releases.  Changing to a build system that uses python3 to parse JSON
like files to generate ninja would change that.

> 
> > How does meson handle build file backwards compatibility between meson
> > versions? I don't intend to flame, but I've found for some reason many
> > python projects don't seem to take this very seriously. Either having
> > conditionals in build files to support building with several meson
> > versions or always requiring the latest and greatest version would be
> > rather annoying.
> 
> Meson makes backwards compatible changes, and the version can be queried using
> `meson.version()`, which works using meson's version comparison mechanism. I
> would say this about meson, it's not a 'python project', it's 'a project 
> written
> in python', and they've taken great pains to not expose python in meson, and
> reserve the right to reimplement in a different language if python becomes an
> issue.
> 
> 
> > BR,
> > Jani.
> > 
> > -- 
> > Jani Nikula, Intel Open Source Technology Center
> 
> Dylan



> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> wrote:
> > Seems like we ended up all over the place, so let me try afresh.
> >
> > Above all:
> >  - Saying "I don't care" about your users is arrogant - let us _not_
> > do that, please ?
> 
> Let's be honest, the OpenBSD is subjecting itself to some pretty
> arbitrary restrictions caused including Mesa in its core: 10+ year old
> GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> NetBSD keep Mesa as part of the core operating system, and as such
> don't suffer from these problems.
> 
> For better or worse, they have made their choices and they get to live
> with them. We are not beholden to them.

This isn't a situation like OpenSSH where people explicitly go out of
their way to provide support for and test multiple systems and add
support for horrible things like PAM.  It is more along the lines of
considering integrating patches sent by others to make code build.

> 
> > Even Linux distribution maintainers have responded that "upstream does
> > not care us", which is indicative that we should be more careful what
> > we say.
> 
> Citation needed.
> 
> > For the rest - we're dealing with two orthogonal issues here:
> >
> > * Multiple build systems
> > I believe we'll all agree that I might be the person who's been in all
> > the build systems the most.
> > Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
> 
> No one is advocating dropping all of the existing build systems yet.
> 
> This patch is an RFC for a smaller project to start the discussion about Mesa.
> 
> >  - [currently] there is no viable solution for Android
> 
> Acknowledged. Dylan is going to see if this is something that can be
> solved in upstream Meson.
> 
> >  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> > write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> > boat.
> 
> Solaris is a closed source operating system whose developers do not
> contribute to the project. We do not need to base our decisions on
> them.

So Mesa will remove support for libglvnd then?  I don't see a lot of
open source non-Mesa alternatives for libGL.

Oh and the mingw, windows and macos support can go as well, great!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
> 
> 
> On 21/03/17 06:39, Emil Velikov wrote:
> > On 20 March 2017 at 18:30, Matt Turner <matts...@gmail.com> wrote:
> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.veli...@gmail.com> 
> > > wrote:
> > > > Seems like we ended up all over the place, so let me try afresh.
> > > > 
> > > > Above all:
> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
> > > > do that, please ?
> > > 
> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
> > > GCC,
> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> > wasn't OpenBSD to blame here ;-)
> 
> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
> 
> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> rather not go through the upgrade hassle if I don't have to."
> 
> Followed by Jose "We're internally building and shipping Mesa compiled with
> GCC 4.4 (more specifically 4.4.3).
> 
> It's fine if you require GCC 4.8 on automake, but please leave support
> for GCC 4.4.x in SCons."
> 
> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> various features backported, from what I understand Mesa would not build on
> a real GCC 4.2 release and we should not be using it as a min version. IMO
> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> the min GCC version.
> 
> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
> deal with it if we move on.

I would like to see Mesa test features it uses in configure rather than
arbitary versions that are what a certain linux distribution ships with.
The zlib change for instance didn't reference any specific problems with
older versions or interfaces required from newer versions.

We have one platform using clang/lld now (arm64) and are likely to move
others in future where possible.  libtool has to be patched and the Mesa
configure script regenerated to make this work or Mesa won't build due
to libtool.m4 looking for specific strings in ld -v produced by bfd
binutils or gold...

And yes if you change the configure script to check for a newer version
I'll revert it locally like I did with the zlib one.

As I get the impression no one cares about patches for older GCC I've
not being sending them to the list, ie

commit d3d340d6026e516cc405a2eb1d925a7a7a467480
Author: Jonathan Gray <j...@jsg.id.au>
Date:   Thu Mar 16 00:30:07 2017 +1100

i965: don't use designated array initialisation

Don't use a form of designated array initialisation that breaks gcc 4.2.1.

compiler/brw_vec4_gs_visitor.cpp:589: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:590: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:591: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:592: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:593: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:594: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:595: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:596: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:597: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:598: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:599: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:600: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:601: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:602: error: expected primary-expression 
before '[' token

Signed-off-by: Jonathan Gray <j...@jsg.id.au>

diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp 
b/src/intel/compiler/brw_vec4_gs_visitor.cpp
index 4a8b5be30e..e7a502306e 100644
--- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
+++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
@@ -585,23 +585,6 @@ vec4_gs_visitor::gs_end_primitive()
emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
 }
 
-static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
-   [GL_POINTS] =_3DPRIM_POINTLIST,
-   [GL_LINES] = _3DPRIM_LINELIST,
-   [GL_LINE

Re: [Mesa-dev] [PATCH] i965: Shut up major()/minor() warnings.

[Jonathan Gray]

On Mon, Mar 20, 2017 at 04:05:04PM -0700, Kenneth Graunke wrote:
> Recent glibc generates this warning:
> 
> brw_performance_query.c:1648:13: warning: In the GNU C Library, "minor" is 
> defined
>  by . For historical compatibility, it is
>  currently defined by  as well, but we plan to
>  remove this soon. To use "minor", include 
>  directly. If you did not intend to use a system-defined macro
>  "minor", you should undefine it after including .
> 
> min = minor(sb.st_rdev);
> 
> So, include sys/sysmacros.h to shut up the warning.

This header is only present on glibc so it should be gated by an ifdef
or it will break all other systems.

minor()/major() are documented as needing sys/types.h and there is no
sys/sysmacro.h on OpenBSD for instance.

> ---
>  src/mesa/drivers/dri/i965/brw_performance_query.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
> b/src/mesa/drivers/dri/i965/brw_performance_query.c
> index 2e04e091d29..17e0d6f0cdf 100644
> --- a/src/mesa/drivers/dri/i965/brw_performance_query.c
> +++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.12.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure.ac: Use POSIX word boundary regex.

[Jonathan Gray]

On Fri, Mar 17, 2017 at 03:45:08PM +0900, Michel D??nzer wrote:
> On 17/03/17 07:42 AM, Vinson Lee wrote:
> > Fixes: fe56c745b8cb ("Convert sed(1) syntax to be compatible with FreeBSD 
> > and OpenBSD")
> 
> Not sure how, since \> was already used (way) before that.

Indeed FreeBSD and OpenBSD libc regex were patched to handle this extension
in 2014.

https://svnweb.freebsd.org/base?view=revision=268066
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/regex/regcomp.c?rev=1.25=text/x-cvsweb-markup
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glapi: avoid using $< in non-suffix make rules

[Jonathan Gray]

Using $< in non-suffix make rules is a GNU extension.  Explicitly use
the name of the python script to fix the build on OpenBSD.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/mapi/glapi/gen/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
index 492f7680bb..c009e47a0d 100644
--- a/src/mapi/glapi/gen/Makefile.am
+++ b/src/mapi/glapi/gen/Makefile.am
@@ -291,10 +291,10 @@ $(MESA_DIR)/main/api_exec.c: gl_genexec.py apiexec.py 
$(COMMON)
$(PYTHON_GEN) $(srcdir)/gl_genexec.py -f $(srcdir)/gl_and_es_API.xml > 
$@
 
 $(MESA_DIR)/main/marshal_generated.c: gl_marshal.py marshal_XML.py $(COMMON)
-   $(PYTHON_GEN) $< -f $(srcdir)/gl_and_es_API.xml > $@
+   $(PYTHON_GEN) $(srcdir)/gl_marshal.py -f $(srcdir)/gl_and_es_API.xml > 
$@
 
 $(MESA_DIR)/main/marshal_generated.h: gl_marshal_h.py marshal_XML.py $(COMMON)
-   $(PYTHON_GEN) $< -f $(srcdir)/gl_and_es_API.xml > $@
+   $(PYTHON_GEN) $(srcdir)/gl_marshal_h.py -f $(srcdir)/gl_and_es_API.xml 
> $@
 
 $(MESA_DIR)/main/dispatch.h: gl_table.py $(COMMON)
$(PYTHON_GEN) $(srcdir)/gl_table.py -f $(srcdir)/gl_and_es_API.xml -m 
remap_table > $@
-- 
2.12.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Thu, Mar 16, 2017 at 09:12:38PM -0700, Dylan Baker wrote:
> quoting jason ekstrand (2017-03-16 19:03:15)
> > on march 16, 2017 5:41:24 pm emil velikov  wrote:
> > > and meson is not a thing on neither bsd(s), solaris (and derivatives) nor 
> > > android :-\
> > 
> > i have trouble bringing myself to care.  the bsds need to stop using 10 
> > year old compilers.  it can be made to work on solaris and bsd if someone 
> > bothered to put a little work into it.  besides, given that large chunks of 
> > gnome are switching they're going to have to make it work some day soon 
> > anyway.
> 
> I decided to check the ports on my freebsd box, it has meson, in fact:
> freebsd: https://svnweb.freebsd.org/ports/head/devel/meson/
> netbsd: http://pkgsrc.se/wip/py-meson
> openbsd: http://ports.su/devel/meson
> 
> The only OS I couldn't find a package for is openindiana (the clostest thing 
> to
> Solaris I could come up with), but there is ninja for Solaris, and meson 
> itself
> is pure python installable via pip, so even there it's not impossible.
> 
> Dylan

OpenBSD has libdrm in the xenocara tree.  If libdrm were to switch
build systems I'd have to maintain a different build system for it.

There are effectively three source trees in OpenBSD.  src with kernel
posix utilities, toolchain etc.  xenocara with xorg, Mesa, fonts.
ports with everything else.  src is self contained, xenocara can
only take dependencies on src and other parts of xenocara.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: avoid using a GNU make pattern rule

[Jonathan Gray]

% pattern rules are a GNU extension.  As there is only one file here
avoid patterns and globbing entirely to fix the build on non-GNU make.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/mesa/drivers/dri/i965/Makefile.am | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index a83e3a6fa1..fee1ccbbf5 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -92,8 +92,8 @@ EXTRA_DIST = \
 # .c and .h files in one go so we don't hit problems with parallel
 # make and multiple invocations of the same script trying to write
 # to the same files.
-brw_oa_%.h: brw_oa_%.xml brw_oa.py Makefile.am
-   $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/brw_oa.py 
--header=$(builddir)/brw_oa_$(*).h --chipset="$(*)" $(srcdir)/brw_oa_$(*).xml
-brw_oa_%.c: brw_oa_%.xml brw_oa.py Makefile.am
-   $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/brw_oa.py 
--code=$(builddir)/brw_oa_$(*).c --chipset="$(*)" $(srcdir)/brw_oa_$(*).xml
+brw_oa_hsw.h: $(srcdir)/brw_oa_hsw.xml
+   $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/brw_oa.py 
--header=$(builddir)/brw_oa_hsw.h --chipset=hsw $(srcdir)/brw_oa_hsw.xml
+brw_oa_hsw.c: $(srcdir)/brw_oa_hsw.xml
+   $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/brw_oa.py 
--code=$(builddir)/brw_oa_hsw.c --chipset=hsw $(srcdir)/brw_oa_hsw.xml
 
-- 
2.12.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: remove uneeded asm/unistd.h include

[Jonathan Gray]

Fix the build on OpenBSD by removing an uneeded include for asm/unistd.h.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/mesa/drivers/dri/i965/brw_performance_query.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
b/src/mesa/drivers/dri/i965/brw_performance_query.c
index 64b3beeeae..4052117ea5 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
@@ -42,7 +42,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
-- 
2.12.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] i965: Implement INTEL_performance_query backend

[Jonathan Gray]

On Thu, Feb 16, 2017 at 01:20:37PM +, Robert Bragg wrote:
> diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
> b/src/mesa/drivers/dri/i965/brw_performance_query.c
> new file mode 100644
> index 00..f1b6f583bf
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
> +/**
> + * \file brw_performance_query.c
> + *
> + * Implementation of the GL_INTEL_performance_query extension.
> + *
> + * Currently this driver only exposes the 64bit Pipeline Statistics
> + * Registers for Gen6+, with support for Observability Counters to be
> + * added later for Gen7.5+
> + */
> +
> +#include 
> +
> +#include 

Is this include needed on Linux?  It broke the Mesa build on OpenBSD
and builds fine with it removed here.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "main/hash.h"
> +#include "main/macros.h"
> +#include "main/mtypes.h"
> +#include "main/performance_query.h"
> +
> +#include "util/bitset.h"
> +#include "util/ralloc.h"
> +
> +#include "brw_context.h"
> +#include "brw_defines.h"
> +#include "brw_performance_query.h"
> +#include "intel_batchbuffer.h"
> +
> +#define FILE_DEBUG_FLAG DEBUG_PERFMON
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util/build-id: define ElfW and NT_GNU_BUILD_ID if needed

[Jonathan Gray]

Define ElfW() and NT_GNU_BUILD_ID if needed as these defines are not
present on at least OpenBSD and FreeBSD.  Fixes the build on OpenBSD.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/util/build_id.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/util/build_id.c b/src/util/build_id.c
index 2993a80cfe..cc0f852730 100644
--- a/src/util/build_id.c
+++ b/src/util/build_id.c
@@ -28,6 +28,14 @@
 
 #include "build_id.h"
 
+#ifndef NT_GNU_BUILD_ID
+#define NT_GNU_BUILD_ID 3
+#endif
+
+#ifndef ElfW
+#define ElfW(type) Elf_##type
+#endif
+
 #define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) - 1))
 
 struct build_id_note {
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] util: Add utility build-id code.

[Jonathan Gray]

On Fri, Feb 17, 2017 at 08:30:17AM -0800, Matt Turner wrote:
> On Fri, Feb 17, 2017 at 5:39 AM, Emil Velikov <emil.l.veli...@gmail.com> 
> wrote:
> > On 17 February 2017 at 01:10, Jonathan Gray <j...@jsg.id.au> wrote:
> >> On Thu, Feb 16, 2017 at 04:25:02PM +, Emil Velikov wrote:
> >>> On 16 February 2017 at 14:23, Jonathan Gray <j...@jsg.id.au> wrote:
> >>> > On Wed, Feb 15, 2017 at 11:11:50AM -0800, Matt Turner wrote:
> >>> >> Provides the ability to read the .note.gnu.build-id section of ELF
> >>> >> binaries, which is inserted by the --build-id=... flag to ld.
> >>> >>
> >>> >> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
> >>> >
> >>> > I don't have time to dig into details right now but this broke the Mesa
> >>> > build on OpenBSD and likely other non-linux platforms:
> >>> >
> >>> > libtool: compile:  gcc -DPACKAGE_NAME=\"Mesa\" 
> >>> > -DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"17.1.0-devel\" 
> >>> > "-DPACKAGE_STRING=\"Mesa 17.1.0-devel\"" 
> >>> > "-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\";
> >>> >  -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"17.1.0-devel\" 
> >>> > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
> >>> > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
> >>> > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
> >>> > -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
> >>> > -DYYTEXT_POINTER=1 -DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_CLZLL=1 
> >>> > -DHAVE___BUILTIN_CTZ=1 -DHAVE___BUILTIN_EXPECT=1 -DHAVE___BUILTIN_FFS=1 
> >>> > -DHAVE___BUILTIN_FFSLL=1 -DHAVE___BUILTIN_POPCOUNT=1 
> >>> > -DHAVE___BUILTIN_POPCOUNTLL=1 -DHAVE_FUNC_ATTRIBUTE_CONST=1 
> >>> > -DHAVE_FUNC_ATTRIBUTE_FLATTEN=1 -DHAVE_FUNC_ATTRIBUTE_FORMAT=1 
> >>> > -DHAVE_FUNC_ATTRIBUTE_MALLOC=1 -DHAVE_FUNC_ATTRIBUTE_PACKED=1 
> >>> > -DHAVE_FUNC_ATTRIBUTE_PURE=1 -DHAVE_FUNC_ATTRIBUTE_UNUSED=1 
> >>> > -DHAVE_FUNC_ATTRIBUTE_VISIBILITY=1 
> >>> > -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT=1 -DHAVE_FUNC_ATTRIBUTE_WEAK=1 
> >>> > -DHAVE_FUNC_ATTRIBUTE_ALIAS=1 -DHAVE_DLADDR=1 -DHAVE_CLOCK_GETTIME=1 
> >>> > -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -I. 
> >>> > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> >>> > -DDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_SYS_SYSCTL_H 
> >>> > -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR 
> >>> > -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM 
> >>> > -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DENABLE_SHADER_CACHE 
> >>> > -DHAVE_MINCORE -I../../include -I../../src -I../../src/mapi 
> >>> > -I../../src/mesa -I../../src/gallium/include 
> >>> > -I../../src/gallium/auxiliary -fvisibility=hidden -Werror=pointer-arith 
> >>> > -g -O2 -Wall -std=gnu99 -Werror=implicit-function-declaration 
> >>> > -Werror=missing-prototypes -fno-math-errno -fno-trapping-math -MT 
> >>> > libmesautil_la-build_id.lo -MD -MP -MF 
> >>> > .deps/libmesautil_la-build_id.Tpo -c build_id.c  -fPIC -DPIC -o 
> >>> > .libs/libmesautil_la-build_id.o
> >>> > In file included from /usr/include/elf_abi.h:31,
> >>> >  from /usr/include/link_elf.h:10,
> >>> >  from /usr/include/link.h:39,
> >>> >  from build_id.c:25:
> >>> > /usr/include/sys/exec_elf.h:585: error: expected 
> >>> > specifier-qualifier-list before 'uint32_t'
> >>> > In file included from /usr/include/link.h:39,
> >>> >  from build_id.c:25:
> >>> > /usr/include/link_elf.h:22: error: expected specifier-qualifier-list 
> >>> > before 'caddr_t'
> >>> > /usr/include/link_elf.h:37: error: expected '=', ',', ';', 'asm' or 
> >>> > '__attribute__' before 'int'
> >>> > In file included from build_id.c:25:
> >>> > /usr/include/link.h:49: error: expected '=', ',', ';', 'asm' or 
> >>> > '__attribute__' before 'struct'
> >>> > /usr/include/link.h:65: error: expected specifier-qualifier-list before 
> >>>

Re: [Mesa-dev] [PATCH 1/2] util: Add utility build-id code.

[Jonathan Gray]

On Thu, Feb 16, 2017 at 04:25:02PM +, Emil Velikov wrote:
> On 16 February 2017 at 14:23, Jonathan Gray <j...@jsg.id.au> wrote:
> > On Wed, Feb 15, 2017 at 11:11:50AM -0800, Matt Turner wrote:
> >> Provides the ability to read the .note.gnu.build-id section of ELF
> >> binaries, which is inserted by the --build-id=... flag to ld.
> >>
> >> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
> >
> > I don't have time to dig into details right now but this broke the Mesa
> > build on OpenBSD and likely other non-linux platforms:
> >
> > libtool: compile:  gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" 
> > -DPACKAGE_VERSION=\"17.1.0-devel\" "-DPACKAGE_STRING=\"Mesa 17.1.0-devel\"" 
> > "-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\";
> >  -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"17.1.0-devel\" 
> > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
> > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
> > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
> > -DYYTEXT_POINTER=1 -DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_CLZLL=1 
> > -DHAVE___BUILTIN_CTZ=1 -DHAVE___BUILTIN_EXPECT=1 -DHAVE___BUILTIN_FFS=1 
> > -DHAVE___BUILTIN_FFSLL=1 -DHAVE___BUILTIN_POPCOUNT=1 
> > -DHAVE___BUILTIN_POPCOUNTLL=1 -DHAVE_FUNC_ATTRIBUTE_CONST=1 
> > -DHAVE_FUNC_ATTRIBUTE_FLATTEN=1 -DHAVE_FUNC_ATTRIBUTE_FORMAT=1 
> > -DHAVE_FUNC_ATTRIBUTE_MALLOC=1 -DHAVE_FUNC_ATTRIBUTE_PACKED=1 
> > -DHAVE_FUNC_ATTRIBUTE_PURE=1 -DHAVE_FUNC_ATTRIBUTE_UNUSED=1 
> > -DHAVE_FUNC_ATTRIBUTE_VISIBILITY=1 
> > -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT=1 -DHAVE_FUNC_ATTRIBUTE_WEAK=1 
> > -DHAVE_FUNC_ATTRIBUTE_ALIAS=1 -DHAVE_DLADDR=1 -DHAVE_CLOCK_GETTIME=1 
> > -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -I. -D__STDC_CONSTANT_MACROS 
> > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DDEBUG 
> > -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF 
> > -DHAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN 
> > -DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING 
> > -DENABLE_SHADER_CACHE -DHAVE_MINCORE -I../../include -I../../src 
> > -I../../src/mapi -I../../src/mesa -I../../src/gallium/include 
> > -I../../src/gallium/auxiliary -fvisibility=hidden -Werror=pointer-arith -g 
> > -O2 -Wall -std=gnu99 -Werror=implicit-function-declaration 
> > -Werror=missing-prototypes -fno-math-errno -fno-trapping-math -MT 
> > libmesautil_la-build_id.lo -MD -MP -MF .deps/libmesautil_la-build_id.Tpo -c 
> > build_id.c  -fPIC -DPIC -o .libs/libmesautil_la-build_id.o
> > In file included from /usr/include/elf_abi.h:31,
> >  from /usr/include/link_elf.h:10,
> >  from /usr/include/link.h:39,
> >  from build_id.c:25:
> > /usr/include/sys/exec_elf.h:585: error: expected specifier-qualifier-list 
> > before 'uint32_t'
> > In file included from /usr/include/link.h:39,
> >  from build_id.c:25:
> > /usr/include/link_elf.h:22: error: expected specifier-qualifier-list before 
> > 'caddr_t'
> > /usr/include/link_elf.h:37: error: expected '=', ',', ';', 'asm' or 
> > '__attribute__' before 'int'
> > In file included from build_id.c:25:
> > /usr/include/link.h:49: error: expected '=', ',', ';', 'asm' or 
> > '__attribute__' before 'struct'
> > /usr/include/link.h:65: error: expected specifier-qualifier-list before 
> > 'caddr_t'
> These look like issue in your platform code/headers. Perhaps some bad
> interaction with the bits that Mesa defines ?
> 
> Quick workaround is to check the function only when needed, roughly
> like this pseudo code:
> 
> if test $building_any_vulkan_driver = yes ;then
> require_dl...=yes
>
> fi
> 
> 
> if test $require_dl... = yes ; then
>AC_CHECK_FUNC([dl_iterate_phdr], [DEFINES="$DEFINES
> -DHAVE_DL_ITERATE_PHDR"], [AC_MSG_ERROR([required  not found])])
> fi
> 
> 
> Please give it a bash and send us a patch that works on your end.

Leaning towards something along the lines of the following.
With Nhdr struct definitions added to system exec_elf.h.

The need for sys/types.h here may go away shortly as well.

diff --git a/src/util/build_id.c b/src/util/build_id.c
index 2993a80cfe..92250a1f5f 100644
--- a/src/util/build_id.c
+++ b/src/util/build_id.c
@@ -22,12 +22,22 @@
  */
 
 #ifdef HAVE_DL_ITERATE_PHDR
+
+#include 
 #include 
 #include 
 #include 
 
 #include "build_id.h"
 
+#ifndef NT_GNU_BUILD_ID
+#define NT_GNU_BUILD_ID 3
+#endif
+
+#ifndef ElfW
+#define ElfW(type) Elf_##type
+#endif
+
 #define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) - 1))
 
 struct build_id_note {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] util: Add utility build-id code.

[Jonathan Gray]

On Wed, Feb 15, 2017 at 11:11:50AM -0800, Matt Turner wrote:
> Provides the ability to read the .note.gnu.build-id section of ELF
> binaries, which is inserted by the --build-id=... flag to ld.
> 
> Reviewed-by: Emil Velikov 

I don't have time to dig into details right now but this broke the Mesa
build on OpenBSD and likely other non-linux platforms:

libtool: compile:  gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" 
-DPACKAGE_VERSION=\"17.1.0-devel\" "-DPACKAGE_STRING=\"Mesa 17.1.0-devel\"" 
"-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\";
 -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"17.1.0-devel\" 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DYYTEXT_POINTER=1 -DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_CLZLL=1 
-DHAVE___BUILTIN_CTZ=1 -DHAVE___BUILTIN_EXPECT=1 -DHAVE___BUILTIN_FFS=1 
-DHAVE___BUILTIN_FFSLL=1 -DHAVE___BUILTIN_POPCOUNT=1 
-DHAVE___BUILTIN_POPCOUNTLL=1 -DHAVE_FUNC_ATTRIBUTE_CONST=1 
-DHAVE_FUNC_ATTRIBUTE_FLATTEN=1 -DHAVE_FUNC_ATTRIBUTE_FORMAT=1 
-DHAVE_FUNC_ATTRIBUTE_MALLOC=1 -DHAVE_FUNC_ATTRIBUTE_PACKED=1 
-DHAVE_FUNC_ATTRIBUTE_PURE=1 -DHAVE_FUNC_ATTRIBUTE_UNUSED=1 
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY=1 -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT=1 
-DHAVE_FUNC_ATTRIBUTE_WEAK=1 -DHAVE_FUNC_ATTRIBUTE_ALIAS=1 -DHAVE_DLADDR=1 
-DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -I. 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DDEBUG 
-DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF 
-DHAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN 
-DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING 
-DENABLE_SHADER_CACHE -DHAVE_MINCORE -I../../include -I../../src 
-I../../src/mapi -I../../src/mesa -I../../src/gallium/include 
-I../../src/gallium/auxiliary -fvisibility=hidden -Werror=pointer-arith -g -O2 
-Wall -std=gnu99 -Werror=implicit-function-declaration 
-Werror=missing-prototypes -fno-math-errno -fno-trapping-math -MT 
libmesautil_la-build_id.lo -MD -MP -MF .deps/libmesautil_la-build_id.Tpo -c 
build_id.c  -fPIC -DPIC -o .libs/libmesautil_la-build_id.o
In file included from /usr/include/elf_abi.h:31,
 from /usr/include/link_elf.h:10,
 from /usr/include/link.h:39,
 from build_id.c:25:
/usr/include/sys/exec_elf.h:585: error: expected specifier-qualifier-list 
before 'uint32_t'
In file included from /usr/include/link.h:39,
 from build_id.c:25:
/usr/include/link_elf.h:22: error: expected specifier-qualifier-list before 
'caddr_t'
/usr/include/link_elf.h:37: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'int'
In file included from build_id.c:25:
/usr/include/link.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before 'struct'
/usr/include/link.h:65: error: expected specifier-qualifier-list before 
'caddr_t'
build_id.c:34: error: expected specifier-qualifier-list before 'ElfW'
build_id.c: In function 'build_id_find_nhdr_callback':
build_id.c:63: error: 'struct build_id_note' has no member named 'nhdr'
build_id.c:63: error: 'NT_GNU_BUILD_ID' undeclared (first use in this function)
build_id.c:63: error: (Each undeclared identifier is reported only once
build_id.c:63: error: for each function it appears in.)
build_id.c:64: error: 'struct build_id_note' has no member named 'nhdr'
build_id.c:65: error: 'struct build_id_note' has no member named 'nhdr'
build_id.c:66: error: 'struct build_id_note' has no member named 'name'
build_id.c:71: warning: implicit declaration of function 'ElfW'
build_id.c:71: error: 'Nhdr' undeclared (first use in this function)
build_id.c:72: error: 'struct build_id_note' has no member named 'nhdr'
build_id.c:73: error: 'struct build_id_note' has no member named 'nhdr'
build_id.c: In function 'build_id_find_nhdr':
build_id.c:90: warning: implicit declaration of function 'dl_iterate_phdr'
build_id.c: In function 'build_id_length':
build_id.c:99: error: 'const struct build_id_note' has no member named 'nhdr'
build_id.c: In function 'build_id_read':
build_id.c:106: error: 'const struct build_id_note' has no member named 
'build_id'
*** Error 1 in target 'libmesautil_la-build_id.lo'
mv -f .deps/libmesautil_la-strndup.Tpo .deps/libmesautil_la-strndup.Plo
mv -f sha1/.deps/libmesautil_la-sha1.Tpo sha1/.deps/libmesautil_la-sha1.Plo
*** Error 1 in src/util (Makefile:730 'libmesautil_la-build_id.lo')
*** Error 1 in src/util (Makefile:919 'all-recursive')
*** Error 2 in src/util (Makefile:596 'all')
*** Error 1 in src (Makefile:819 'all-recursive')
*** Error 2 in src (Makefile:584 'all')

adding a sys/types.h include before link.h gets slightly further

libtool: compile:  gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" 

Re: [Mesa-dev] [PATCH] util: import sha1 implementation from OpenBSD

[Jonathan Gray]

On Fri, Jan 13, 2017 at 04:51:31PM +, Emil Velikov wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
> 
> At the moment we support 5+ different implementations each with varying
> amount of bugs - from thread safely problems [1], to outright broken
> implementation(s) [2]
> 
> In order to accommodate these we have 150+ lines of configure script and
> extra two configure toggles. Whist an actual implementation being
> ~200loc and our current compat wrapping ~250.
> 
> Let's not forget that different people use different code paths, thus
> effectively makes it harder to test and debug since the default
> implementation is automatically detected.
> 
> To minimise all these lovely experiences, import the "100% Public
> Domain" OpenBSD sha1 implementation. Clearly document any changes needed
> to get building correctly, since many/most of those can be upstreamed
> making future syncs easier.

I had feared that this would somehow collide with the symbols
in libc but it seems to build and run xorg/glxgears at least
on broadwell with i965.

Patches for OpenBSD go to tech@ and you should look at how portable
openssh and libressl handle systems that lack functions like
explicit_bzero, autoconf detects systems that lack functions or are
known to have broken implementations and alternate versions are
provided.  Damien Miller described how this is handled for ssh in
https://www.openbsd.org/papers/portability.pdf
https://www.openbsd.org/papers/auug2005-portability/

The attribute could also be checked in autoconf as is already done
for various other attributes.

Other parts seem odd, posix defines size_t as being in sys/types.h
not stddef.h for example.

u_int* are bsd types which predate c99 types, I could see an
argument being made for changing the types there but it
would likely have to cover all the other hashes as well,
not just sha1.

> 
> As an added bonus this will avoid all the 'fun' experiences trying to
> integrate it with the Android and SCons builds.
> 
> Bugzilla [1]: https://bugs.freedesktop.org/show_bug.cgi?id=94904
> Bugzilla [2]: https://bugs.freedesktop.org/show_bug.cgi?id=97967
> Cc: Mark Janes <mark.a.ja...@intel.com>
> Cc: Vinson Lee <v...@freedesktop.org>
> Cc: Tapani P??lli <tapani.pa...@intel.com>
> Cc: Jonathan Gray <j...@jsg.id.au>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  configure.ac | 161 +--
>  src/compiler/glsl/tests/cache_test.c |   5 -
>  src/mesa/main/shaderapi.c|   6 -
>  src/util/Makefile.am |   3 -
>  src/util/Makefile.sources|   2 +
>  src/util/SConscript  |   5 -
>  src/util/disk_cache.c|   4 -
>  src/util/disk_cache.h|  42 --
>  src/util/mesa-sha1.c | 242 
> +--
>  src/util/sha1/README |  55 
>  src/util/sha1/sha1.c | 173 +
>  src/util/sha1/sha1.h |  47 +++
>  12 files changed, 279 insertions(+), 466 deletions(-)
>  create mode 100644 src/util/sha1/README
>  create mode 100644 src/util/sha1/sha1.c
>  create mode 100644 src/util/sha1/sha1.h
> 
> diff --git a/configure.ac b/configure.ac
> index 459f3e8b0a..5772b378c7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -9,7 +9,6 @@ dnl Copyright ?? 2009-2014 Jon TURNEY
>  dnl Copyright ?? 2011-2012 Benjamin Franzke
>  dnl Copyright ?? 2008-2014 David Airlie
>  dnl Copyright ?? 2009-2013 Brian Paul
> -dnl Copyright ?? 2003-2007 Keith Packard, Daniel Stone
>  dnl
>  dnl Permission is hereby granted, free of charge, to any person obtaining a
>  dnl copy of this software and associated documentation files (the 
> "Software"),
> @@ -1432,151 +1431,6 @@ if test "x$enable_gallium_osmesa" = xyes; then
>  fi
>  fi
>  
> -# SHA1 hashing
> -AC_ARG_WITH([sha1],
> -
> [AS_HELP_STRING([--with-sha1=libc|libmd|libnettle|libgcrypt|libcrypto|libsha1|CommonCrypto|CryptoAPI],
> -[choose SHA1 implementation])])
> -case "x$with_sha1" in
> -x | xlibc | xlibmd | xlibnettle | xlibgcrypt | xlibcrypto | xlibsha1 | 
> xCommonCrypto | xCryptoAPI)
> -  ;;
> -*)
> -AC_MSG_ERROR([Illegal value for --with-sha1: $with_sha1])
> -esac
> -
> -AC_CHECK_FUNC([SHA1Init], [HAVE_SHA1_IN_LIBC=yes])
> -if test "x$with_sha1" = x && test "x$HAVE_SHA1_IN_LIBC" = xyes; then
> - with_sha1=libc
> -fi
> -if test "x$with_sha1" = xlibc && test "x$HAVE_SHA1_IN_LIBC" != xyes; then
> - AC_MSG_ERROR([sha1 in libc requested but not found])
> -fi
> -if test "x$with

Re: [Mesa-dev] [PATCH] mesa: don't attempt to unlock an unlocked debug state mutex

[Jonathan Gray]

On Tue, Dec 20, 2016 at 11:52:26AM -0800, Kenneth Graunke wrote:
> On Tuesday, December 20, 2016 12:08:06 PM PST Jonathan Gray wrote:
> > Can someone push this to master?
> 
> Pushed:
> 
> To ssh://git.freedesktop.org/git/mesa/mesa
>ab8ea1b..62b8bcd  master -> master
> 
> Have you thought about applying for commit access?

Thanks, I'll look into that in future.

I assume the part about only accepting rsa ssh keys on
https://www.freedesktop.org/wiki/AccountRequests/
is outdated with ecdsa and ed25519 keys also being accepted?

Though perhaps that is a question better put to the fdo admins.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: don't attempt to unlock an unlocked debug state mutex

[Jonathan Gray]

Can someone push this to master?

On Sun, Dec 11, 2016 at 07:21:36PM +0100, Eduardo Lima Mitev wrote:
> Looks good.
> 
> Reviewed-by: Eduardo Lima Mitev <el...@igalia.com>
> 
> On 12/11/2016 04:42 PM, Jonathan Gray wrote:
> > Commit 929fcee47e46781c57f2a354ce0a013915c033d1 introduced code that
> > attempts to unlock an unlocked mutex which is undefined behaviour.
> > 
> > On OpenBSD this leads to an abort:
> > 
> > 0  0x124dadfa96ba in thrkill () at :2
> > 1  0x124dadf3da39 in *_libc_abort () at 
> > /usr/src/lib/libc/stdlib/abort.c:52
> > 2  0x124d2c1165b5 in *_libpthread_pthread_mutex_unlock 
> > (mutexp=)
> > at /usr/src/lib/librthread/rthread_sync.c:221
> > 3  0x124d279c02e4 in init_attrib_groups (ctx=0x124df0fda000) at 
> > main/context.c:825
> > 4  _mesa_initialize_context (ctx=ctx@entry=0x124df0fda000, 
> > api=api@entry=API_OPENGL_CORE,
> > visual=visual@entry=0x7f7bdfd0, share_list=share_list@entry=0x0,
> > driverFunctions=driverFunctions@entry=0x7f7bda60) at 
> > main/context.c:1204
> > 5  0x124d27b507ec in st_create_context (api=api@entry=API_OPENGL_CORE,
> > pipe=pipe@entry=0x124dc491, visual=visual@entry=0x7f7bdfd0,
> > share=share@entry=0x0, options=options@entry=0x7f7be128)
> > at state_tracker/st_context.c:545
> > 6  0x124d27b8639f in st_api_create_context (stapi=,
> > smapi=0x124d1b608800, attribs=0x7f7be100, error=0x7f7be0fc, 
> > shared_stctxi=0x0)
> > at state_tracker/st_manager.c:669
> > 7  0x124d27cc5b9c in dri_create_context (api=, 
> > visual=0x124d8a0f8a00,
> > cPriv=0x124de473f240, major_version=, 
> > minor_version=,
> > flags=, notify_reset=false, error=0x7f7be2b4,
> > sharedContextPrivate=0x0) at dri_context.c:123
> > 8  0x124d27cc5029 in driCreateContextAttribs (screen=0x124d8a0f8400,
> > api=, config=0x124d8a0f8a00, shared=,
> > num_attribs=, attribs=, 
> > error=0x7f7be2b4,
> > data=0x124d77814a00) at dri_util.c:448
> > 9  0x124d8e109b00 in drisw_create_context_attribs (base=0x124df3e08700,
> > config_base=0x124d7a0e7300, shareList=, 
> > num_attribs=,
> > attribs=, error=0x7f7ffffbe2b4) at drisw_glx.c:476
> > 10 0x124d8e104b4a in glXCreateContextAttribsARB (dpy=0x124d533f,
> > config=0x124d7a0e7300, share_context=0x0, direct=1, 
> > attrib_list=0x7f7be300)
> > at create_context.c:78
> > 
> > Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> > ---
> >  src/mesa/main/debug_output.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
> > index 48dbbb3..bc933db 100644
> > --- a/src/mesa/main/debug_output.c
> > +++ b/src/mesa/main/debug_output.c
> > @@ -1282,14 +1282,13 @@ _mesa_init_debug_output(struct gl_context *ctx)
> > */
> >struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
> >if (!debug) {
> > - goto done;
> > + return;
> >}
> >debug->DebugOutput = GL_TRUE;
> >debug->LogToStderr = GL_TRUE;
> >ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_DEBUG_BIT;
> > +  _mesa_unlock_debug_state(ctx);
> > }
> > -done:
> > -   _mesa_unlock_debug_state(ctx);
> >  }
> >  
> >  
> > 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-maintainers] Proposal of date-based Mesa versioning for 2017

[Jonathan Gray]

On Mon, Dec 12, 2016 at 03:28:45PM +, Emil Velikov wrote:
> [adding mesa-maintainers to the mix]
> 
> On 1 October 2016 at 20:46, Marek Olk  wrote:
> > Hi,
> >
> > I propose that we use versioning in the form of "year.quarter".
> >
> > 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
> > quarters of the year, respectively.
> > 2018 would start with 18.0, then 18.1, 18.2, 18.3.
> >
> > The motivation is that you can easily tell when a specific Mesa
> > version was released with an accuracy of 3 months.
> >
> > That's the only scheme that seems practical to me. Everything else
> > seems arbitrary or random.
> >
> Afaict the only expectation from version numbers, is to never go back
> in time. Anything else is a manner of personal interpretation and
> there is will always someone who get confused.
> Look at how [some] projects steadily roll in their 50s ;-)
> 
> That said, having a bit of a change is a good idea, esp. since we're
> unlikely to have a major bump anytime soon.
> 
> As mentioned by others - having the second number represent the month
> would be better, afaict.
> Namely: YY.MM.PP. Thus 17.02.01 provides direct and clear feedback that
>  - 2017 release, from the second month (Feb).
>  - first bugfix release.
> 
>  * Distro/package maintainers, let us know if the above sounds fine on your 
> end.
> 
> Since this will have an impact on the tarball URL I'm bringing forward
> a question which has been asked a few times:
> 
>  * Should we drop the $VERSION directory in the URL, since it causes a
> fair bit of nuisance during RC stage.
> Namely from:
> https://mesa.freedesktop.org/archive/$VERSION/mesa-$VERSION.tar.{xz,gz}
> to:
> https://mesa.freedesktop.org/archive/mesa-$VERSION.tar.{xz,gz}
> 
> Maintainers, kindly reply on both topics, even if you're neutral.

On the OpenBSD side, Mesa is imported into a larger tree (xenocara)
which has libdrm, xorg, fonts etc, so location of the distfile isn't a
problem.  The version would only show up in the form of pkg-config
files and the version strings accessible from GL contexts.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: don't attempt to unlock an unlocked debug state mutex

[Jonathan Gray]

Previously there was no _mesa_unlock_debug_state() call at all,
one is still retained here for the case where _mesa_lock_debug_state()
is called and did not return NULL (which is documented as being
unlocked).

On Mon, Dec 12, 2016 at 11:40:32AM +1100, Edward O'Callaghan wrote:
> Hold up..
> 
> Does this reintroduce the hang in glsl-fs-loop piglit test with
> MESA_DEBUG=context though? Was that tested? I'm interested to know how
> this got so muddled up in the first place.
> 
> Kind Regards,
> Edward.
> 
> On 12/12/2016 05:21 AM, Eduardo Lima Mitev wrote:
> > Looks good.
> > 
> > Reviewed-by: Eduardo Lima Mitev <el...@igalia.com>
> > 
> > On 12/11/2016 04:42 PM, Jonathan Gray wrote:
> >> Commit 929fcee47e46781c57f2a354ce0a013915c033d1 introduced code that
> >> attempts to unlock an unlocked mutex which is undefined behaviour.
> >>
> >> On OpenBSD this leads to an abort:
> >>
> >> 0  0x124dadfa96ba in thrkill () at :2
> >> 1  0x124dadf3da39 in *_libc_abort () at 
> >> /usr/src/lib/libc/stdlib/abort.c:52
> >> 2  0x124d2c1165b5 in *_libpthread_pthread_mutex_unlock 
> >> (mutexp=)
> >> at /usr/src/lib/librthread/rthread_sync.c:221
> >> 3  0x124d279c02e4 in init_attrib_groups (ctx=0x124df0fda000) at 
> >> main/context.c:825
> >> 4  _mesa_initialize_context (ctx=ctx@entry=0x124df0fda000, 
> >> api=api@entry=API_OPENGL_CORE,
> >> visual=visual@entry=0x7f7bdfd0, share_list=share_list@entry=0x0,
> >> driverFunctions=driverFunctions@entry=0x7f7bda60) at 
> >> main/context.c:1204
> >> 5  0x124d27b507ec in st_create_context (api=api@entry=API_OPENGL_CORE,
> >> pipe=pipe@entry=0x124dc491, visual=visual@entry=0x7f7bdfd0,
> >> share=share@entry=0x0, options=options@entry=0x7f7be128)
> >> at state_tracker/st_context.c:545
> >> 6  0x124d27b8639f in st_api_create_context (stapi=,
> >> smapi=0x124d1b608800, attribs=0x7f7be100, error=0x7f7be0fc, 
> >> shared_stctxi=0x0)
> >> at state_tracker/st_manager.c:669
> >> 7  0x124d27cc5b9c in dri_create_context (api=, 
> >> visual=0x124d8a0f8a00,
> >> cPriv=0x124de473f240, major_version=, 
> >> minor_version=,
> >> flags=, notify_reset=false, error=0x7f7be2b4,
> >> sharedContextPrivate=0x0) at dri_context.c:123
> >> 8  0x124d27cc5029 in driCreateContextAttribs (screen=0x124d8a0f8400,
> >> api=, config=0x124d8a0f8a00, shared=,
> >> num_attribs=, attribs=, 
> >> error=0x7f7be2b4,
> >> data=0x124d77814a00) at dri_util.c:448
> >> 9  0x124d8e109b00 in drisw_create_context_attribs (base=0x124df3e08700,
> >> config_base=0x124d7a0e7300, shareList=, 
> >> num_attribs=,
> >> attribs=, error=0x7f7be2b4) at drisw_glx.c:476
> >> 10 0x124d8e104b4a in glXCreateContextAttribsARB (dpy=0x124d533f,
> >> config=0x124d7a0e7300, share_context=0x0, direct=1, 
> >> attrib_list=0x7f7be300)
> >> at create_context.c:78
> >>
> >> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> >> ---
> >>  src/mesa/main/debug_output.c | 5 ++---
> >>  1 file changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
> >> index 48dbbb3..bc933db 100644
> >> --- a/src/mesa/main/debug_output.c
> >> +++ b/src/mesa/main/debug_output.c
> >> @@ -1282,14 +1282,13 @@ _mesa_init_debug_output(struct gl_context *ctx)
> >> */
> >>struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
> >>if (!debug) {
> >> - goto done;
> >> + return;
> >>}
> >>debug->DebugOutput = GL_TRUE;
> >>debug->LogToStderr = GL_TRUE;
> >>ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_DEBUG_BIT;
> >> +  _mesa_unlock_debug_state(ctx);
> >> }
> >> -done:
> >> -   _mesa_unlock_debug_state(ctx);
> >>  }
> >>  
> >>  
> >>
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> 



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: don't attempt to unlock an unlocked debug state mutex

[Jonathan Gray]

Commit 929fcee47e46781c57f2a354ce0a013915c033d1 introduced code that
attempts to unlock an unlocked mutex which is undefined behaviour.

On OpenBSD this leads to an abort:

0  0x124dadfa96ba in thrkill () at :2
1  0x124dadf3da39 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
2  0x124d2c1165b5 in *_libpthread_pthread_mutex_unlock (mutexp=)
at /usr/src/lib/librthread/rthread_sync.c:221
3  0x124d279c02e4 in init_attrib_groups (ctx=0x124df0fda000) at 
main/context.c:825
4  _mesa_initialize_context (ctx=ctx@entry=0x124df0fda000, 
api=api@entry=API_OPENGL_CORE,
visual=visual@entry=0x7f7bdfd0, share_list=share_list@entry=0x0,
driverFunctions=driverFunctions@entry=0x7f7bda60) at main/context.c:1204
5  0x124d27b507ec in st_create_context (api=api@entry=API_OPENGL_CORE,
pipe=pipe@entry=0x124dc491, visual=visual@entry=0x7f7bdfd0,
share=share@entry=0x0, options=options@entry=0x7f7be128)
at state_tracker/st_context.c:545
6  0x124d27b8639f in st_api_create_context (stapi=,
smapi=0x124d1b608800, attribs=0x7f7be100, error=0x7f7be0fc, 
shared_stctxi=0x0)
at state_tracker/st_manager.c:669
7  0x124d27cc5b9c in dri_create_context (api=, 
visual=0x124d8a0f8a00,
cPriv=0x124de473f240, major_version=, 
minor_version=,
flags=, notify_reset=false, error=0x7f7be2b4,
sharedContextPrivate=0x0) at dri_context.c:123
8  0x124d27cc5029 in driCreateContextAttribs (screen=0x124d8a0f8400,
api=, config=0x124d8a0f8a00, shared=,
num_attribs=, attribs=, error=0x7f7be2b4,
data=0x124d77814a00) at dri_util.c:448
9  0x124d8e109b00 in drisw_create_context_attribs (base=0x124df3e08700,
config_base=0x124d7a0e7300, shareList=, 
num_attribs=,
attribs=, error=0x7f7be2b4) at drisw_glx.c:476
10 0x124d8e104b4a in glXCreateContextAttribsARB (dpy=0x124d533f,
config=0x124d7a0e7300, share_context=0x0, direct=1, 
attrib_list=0x7f7be300)
at create_context.c:78

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/mesa/main/debug_output.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
index 48dbbb3..bc933db 100644
--- a/src/mesa/main/debug_output.c
+++ b/src/mesa/main/debug_output.c
@@ -1282,14 +1282,13 @@ _mesa_init_debug_output(struct gl_context *ctx)
*/
   struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
   if (!debug) {
- goto done;
+ return;
   }
   debug->DebugOutput = GL_TRUE;
   debug->LogToStderr = GL_TRUE;
   ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_DEBUG_BIT;
+  _mesa_unlock_debug_state(ctx);
}
-done:
-   _mesa_unlock_debug_state(ctx);
 }
 
 
-- 
2.10.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH libdrm v2 5/5] xf86drm: implement an OpenBSD specific drmGetDevice2

[Jonathan Gray]

On Mon, Dec 05, 2016 at 05:56:40PM +, Emil Velikov wrote:
> On 1 December 2016 at 04:18, Jonathan Gray <j...@jsg.id.au> wrote:
> > DRI devices on OpenBSD are not in their own directory.  They reside in
> > /dev with a large number of statically generated /dev nodes.
> >
> > Avoid stat'ing all of /dev on OpenBSD by implementing this custom path.
> >
> > v2:
> >- use drmGetMinorType to get node type
> >- adapt to drmProcessPciDevice changes
> >- verify drmParseSubsystemType type is PCI
> >- add a comment describing why this was added
> >
> Thanks for the update Jonathan.
> 
> I've pulled v2 in master,
> Emil

Thanks, going over what went in I see drmGetMinorNameForFD and
the OpenBSD drmGetDevice2 paths need to be adjusted to have the correct
minor for the control/render nodes.

ie

base = drmGetMinorBase(type);
if (min < base)
return error;

min -= base;

I'll send another patch for this.

And the common code could be split into a shared function?

drmGetDeviceNameFromFd2 would do the same thing as
drmGetDeviceNameFromFd on OpenBSD as far as I can tell so that could be
another shared function instead of the current "missing implementation"
warning.  Or should drmGetDeviceNameFromFd purposefully not handle
render/control nodes?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 13.0.2 release candidate

[Jonathan Gray]

On Thu, Nov 24, 2016 at 05:25:26PM +, Emil Velikov wrote:
> Hello list,
> 
> The candidate for the Mesa 13.0.2 is now available. Currently we have:
>  - 49 queued
>  - 4 nominated (outstanding)
>  - and 1 rejected patch(es)
> 
> 
> With this series we have - fixes for vc4, i965 and radeon drivers. In addition
> to that PCI IDs for Geminilake have been added to the i965 driver,
> 
> The respective Vulkan drivers have seen multiple improvements some of which
> include improved smoketesting and addressed memory leaks.
> 
> Races during _mesa_HashWalk() (while using glDeleteFramebuffers alongside
> glTexImage2D) and "#version 0" in GLSL programs have been addressed.
> 
> BSD and Hurd users should be above to build the latest code as we no longer
> use PATH_MAX.

You seem to be confusing things there.

BSD has had PATH_MAX since 1989.

commit dcc36b4d161e5d44274cc4bd6d375d04b758b61e
Author: Keith Bostic 
Date:   Thu Feb 16 14:11:48 1989 -0800

system limits for POSIX 1003.1; included by include/limits.h

SCCS-vsn: 7.1

diff --git a/sys/sys/syslimits.h b/sys/sys/syslimits.h
new file mode 100644
index 000..c60f25d
--- /dev/null
+++ b/sys/sys/syslimits.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 1988 The Regents of the University of California.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms are permitted
+ * provided that the above copyright notice and this paragraph are
+ * duplicated in all such forms and that any documentation,
+ * advertising materials, and other materials related to such
+ * distribution and use acknowledge that the software was developed
+ * by the University of California, Berkeley.  The name of the
+ * University may not be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ * @(#)syslimits.h 7.1 (Berkeley) 02/16/89
+ */
+
+#defineARG_MAX 20480   /* max bytes for an exec function */
+#defineCHILD_MAX   40  /* max simultaneous processes */
+#defineLINK_MAX8   /* max file link count */
+#defineMAX_CANON   255 /* max bytes in terminal canonical 
input line */
+#defineMAX_INPUT   255 /* max bytes in terminal input */
+#defineNAME_MAX255 /* max number of bytes in a file name */
+#defineNGROUPS_MAX 16  /* max number of supplemental group 
id's */
+#defineOPEN_MAX64  /* max open files per process */
+#definePATH_MAX1024/* max number of bytes in pathname */
+#definePIPE_BUF512 /* max number of bytes for atomic pipe 
writes */

> 
> 
> Take a look at section "Mesa stable queue" for more information.
> 
> 
> Testing reports/general approval
> 
> Any testing reports (or general approval of the state of the branch) will be
> greatly appreciated.
> 
> The plan is to have 13.0.2 this Saturday (25th of November), around or
> shortly after 17:00 GMT.
> 
> If you have any questions or suggestions - be that about the current patch
> queue or otherwise, please go ahead.
> 
> 
> Trivial merge conflicts
> ---
> commit 9d5c3fc12b05d944508ef4e3b1f2ddc4f23c0a82
> Author: Jason Ekstrand 
> 
> i965/gs: Allow primitive id to be a system value
> 
> (cherry picked from commit a5e88e66e633aaeb587b274d80e21cd46c8ee2cb)
> 
> 
> commit 8dbdbc21910a6d37c381535186f9e728fff8690d
> Author: Jason Ekstrand 
> 
> anv: Handle null in all destructors
> 
> (cherry picked from commit 49f08ad77f51cc344e4bfe60ba9f8d9fccfbd753)
> 
> 
> commit 1809f17bda56d4f9d6385f63a9c4a5df890e3cad
> Author: Kenneth Graunke 
> 
> mesa: Drop PATH_MAX usage.
> 
> (cherry picked from commit 9bfee7047b70cb0aa026ca9536465762f96cb2b1)
> 
> Cheers,
> Emil
> 
> 
> Mesa stable queue
> -
> 
> Nominated (4)
> =
> 
> Dave Airlie (1):
>   2de85eb radv: fix texturesamples to handle single sample case
> 
> Jason Ekstrand (2):
>   e73d136 vulkan/wsi/x11: Implement FIFO mode.
> 
> Note: temporary on hold.
> Commit seems to be a feature and provides no clear indication about the bugs
> it addresses. Jason, is this really applicable for stable ?
> 
>   054e48e anv/cmd_buffer: Re-emit MEDIA_CURBE_LOAD when CS push
> constants are dirty
> 
> Note: temporary on hold.
> Depends on the refactoring d33e2ad67c3 (anv: Move INTERFACE_DESCRIPTOR_DATA
> setup to the pipeline) which in itself depends on another refactoring 
> (cleanup)
> commit 623e1e06d8c and likely others. Jason, any input ?
> 
> Kevin Strasser (1):
>   932bb3f vulkan/wsi: Add a thread-safe queue implementation
> 

Re: [Mesa-dev] [PATCH 1/1] Fix endianess detection with musl-based toolchains

[Jonathan Gray]

On Fri, Nov 04, 2016 at 07:53:25PM +0100, Bernd Kuhls wrote:
> Musl does not define __GLIBC__ and will not provide a __MUSL__ macro:
> http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F
> 
> This patch checks for the presence of endian.h and promotes the result
> to src/amd/Makefile.addrlib.am which executes the broken build command.
> Fixes compile errors detected by the autobuilder infrastructure of the
> buildroot project:

This will break OpenBSD and perhaps other platforms which
have endian.h that does not define glibc definitions.

> 
> http://autobuild.buildroot.net/results/e27/e27a9a95f72dba3076549beb2a2ccfdbea2fcfee/
> http://autobuild.buildroot.net/results/e27/e27a9a95f72dba3076549beb2a2ccfdbea2fcfee/
> Signed-off-by: Bernd Kuhls 
> ---
>  configure.ac| 1 +
>  src/amd/Makefile.addrlib.am | 1 +
>  src/util/u_endian.h | 2 +-
>  3 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 4761c59..7991b52 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -786,6 +786,7 @@ fi
>  AC_HEADER_MAJOR
>  AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
>  AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
> +AC_CHECK_HEADER([endian.h], [DEFINES="$DEFINES -DHAVE_ENDIAN_H"])
>  AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
>  AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
>  
> diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
> index 64823fc..4e2fb1d 100644
> --- a/src/amd/Makefile.addrlib.am
> +++ b/src/amd/Makefile.addrlib.am
> @@ -28,6 +28,7 @@ addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
>   -I$(srcdir)/addrlib/core \
>   -I$(srcdir)/addrlib/inc/chip/r800 \
>   -I$(srcdir)/addrlib/r800/chip \
> + $(DEFINES) \
>   -DBRAHMA_BUILD=1
>  
>  addrlib_libamdgpu_addrlib_la_CXXFLAGS = \
> diff --git a/src/util/u_endian.h b/src/util/u_endian.h
> index b9d563d..266fb4a 100644
> --- a/src/util/u_endian.h
> +++ b/src/util/u_endian.h
> @@ -27,7 +27,7 @@
>  #ifndef U_ENDIAN_H
>  #define U_ENDIAN_H
>  
> -#if defined(__GLIBC__) || defined(ANDROID)
> +#if defined(__GLIBC__) || defined(ANDROID) || defined(HAVE_ENDIAN_H)
>  #include 
>  
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
> -- 
> 2.10.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mapi: automake: set VISIBILITY_CFLAGS for shared glapi

[Jonathan Gray]

shared glapi was previously built without setting CFLAGS for
AM_CFLAGS and VISIBILITY_CFLAGS.

This resulted in symbols being exported that shouldn't be.

The x86 and sparc assembly versions of the dispatch table partially
mitigated this by using .hidden.  Otherwise shared_dispatch_stub_*
were being exported.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
Cc: "11.2 12.0 13.0" <mesa-sta...@lists.freedesktop.org>
---
 src/mapi/Makefile.am | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
index 5a58ca2..f35cedc 100644
--- a/src/mapi/Makefile.am
+++ b/src/mapi/Makefile.am
@@ -64,6 +64,9 @@ BUILT_SOURCES += shared-glapi/glapi_mapi_tmp.h
 
 lib_LTLIBRARIES += shared-glapi/libglapi.la
 shared_glapi_libglapi_la_SOURCES = $(MAPI_GLAPI_FILES) 
shared-glapi/glapi_mapi_tmp.h
+shared_glapi_libglapi_la_CFLAGS = \
+   $(AM_CFLAGS) \
+   $(VISIBILITY_CFLAGS)
 shared_glapi_libglapi_la_CPPFLAGS = \
$(AM_CPPFLAGS) \
-DMAPI_MODE_GLAPI \
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/16] loader: slim down loader_get_pci_id_for_fd implementation(s)

[Jonathan Gray]

On Thu, Oct 20, 2016 at 11:44:46AM +0100, Emil Velikov wrote:
> On 20 October 2016 at 05:35, Jonathan Gray <j...@jsg.id.au> wrote:
> > On Sat, Oct 15, 2016 at 01:32:02PM +0100, Emil Velikov wrote:
> >> On Saturday, 15 October 2016, Jonathan Gray <j...@jsg.id.au> wrote:
> >>
> >> > On Tue, Oct 11, 2016 at 07:31:46PM +0100, Emil Velikov wrote:
> >> > > From: Emil Velikov <emil.veli...@collabora.com <javascript:;>>
> >> > >
> >> > > Currently mesa has three code paths in the loader - libudev, manual
> >> > > sysfs and drm ioctl one.
> >> > >
> >> > > Considering the issues we had with libudev - strip those down in favour
> >> > > of the libdrm drm device API. The latter can be implemented in any way
> >> > > depending on the platform and can be reused by others.
> >> > >
> >> > > Cc: Jonathan Gray <j...@jsg.id.au <javascript:;>>
> >> > > Cc: Jean-S??bastien P??dron <dumbb...@freebsd.org>
> >> > > Signed-off-by: Emil Velikov <emil.veli...@collabora.com <javascript:;>>
> >> > > ---
> >> > > Jonathan, Jean-S??bastien I believe I've prodded you guys for a *BSD
> >> > > implementation of the drm*Device API a while back. With this commit
> >> > > you'll be 'forced' to prep some ;-)
> >> >
> >> > It has been a while since I looked into that.  The design seemed to
> >> > assume that the user running code that called into libdrm had the
> >> > ability to enumerate pci busses.
> >> >
> >> > On OpenBSD /dev/pci* is only read/writable by root.  /dev/drm* is
> >> > chowned after a user logs into a console.
> >> >
> >> > Yes that's correct. The principle is that the platform/kernel has a 
> >> > method
> >> of enumerating and providing basic information for the available devices.
> >> Note that there are multiple applications explicitly dropping OpenBSD
> >> support from their TODO because it lacks the ability [from unprivileged
> >> context].
> >>
> >> We don't use filesystems for communicating with the kernel like linux
> >> > does so ioctls are really the best fit.  The loader parts used at the
> >> > moment use drm driver specific ioctls, hopefully a generic version of
> >> > those that can return the vid/pid, subids and function id numbers would
> >> > cover most of it.
> >>
> >> Afaict retrieving the vendor/device ID et al is not a security concern
> >> (admittedly I'm not a security person) nor drm specific.
> >>
> >> As-is one will end up with multiple implementations - one per subsystem
> >> leading to extra code and maintenance burden on both OpenBSD end and for
> >> apps who want to support the platform.
> >>
> >> Hope that makes things clear and doesn't sound too ranty ;-)
> >> Emil
> >
> > The drm functions in question ask for pci information by passing in
> > major and minor numbers of drm devices or in the case of
> > drmParsePciDeviceInfo bizzarely just "drm0", not sure why the
> > inconsistency there.  They aren't enumerating buses they are responding
> > based on information from drm sources.  So it's going to be drm not pci
> > ioctls.
> >
> One could rework the lot via a) enumerate {PCI,other} devices first,
> b) retrieve bus/device info (vendor/device/nodes) and feed that back
> to the user. In practise the end result should not matter.
> But I have to agree - the current implementation is not that pretty.
> Thus I won't object if one has patches to improve/rewrite it :-)
> 
> Wrt the rest, I'm not sure I fully parse what you're saying. It sounds
> like you've noticed multiple deficiencies, so it'll be better to keep
> that a separate thread
> 
> > The real problem is going to be in adding drm ioctls I'd have to convince
> > the linux kernel people to reserve numbers, people involved in libdrm
> > and people involved in OpenBSD.  Though the functions would then be
> > useable for systems beyond just those with sysfs if they implemented the
> > ioctls.
> >
> Chances are you'll get a Nack straight away from the Linux kernel
> devs. The idea being that a) there's an already existing userspace
> interfaces to do all this stuff and b) the linux kernel ABI must stay
> forever, so people are more cautious what gets added.
> 
> Regardless, please forward what you have in mind to dri-devel, in case
> situation/opinions have changed

Re: [Mesa-dev] [PATCH 02/16] loader: slim down loader_get_pci_id_for_fd implementation(s)

[Jonathan Gray]

On Sat, Oct 15, 2016 at 01:32:02PM +0100, Emil Velikov wrote:
> On Saturday, 15 October 2016, Jonathan Gray <j...@jsg.id.au> wrote:
> 
> > On Tue, Oct 11, 2016 at 07:31:46PM +0100, Emil Velikov wrote:
> > > From: Emil Velikov <emil.veli...@collabora.com <javascript:;>>
> > >
> > > Currently mesa has three code paths in the loader - libudev, manual
> > > sysfs and drm ioctl one.
> > >
> > > Considering the issues we had with libudev - strip those down in favour
> > > of the libdrm drm device API. The latter can be implemented in any way
> > > depending on the platform and can be reused by others.
> > >
> > > Cc: Jonathan Gray <j...@jsg.id.au <javascript:;>>
> > > Cc: Jean-S??bastien P??dron <dumbb...@freebsd.org>
> > > Signed-off-by: Emil Velikov <emil.veli...@collabora.com <javascript:;>>
> > > ---
> > > Jonathan, Jean-S??bastien I believe I've prodded you guys for a *BSD
> > > implementation of the drm*Device API a while back. With this commit
> > > you'll be 'forced' to prep some ;-)
> >
> > It has been a while since I looked into that.  The design seemed to
> > assume that the user running code that called into libdrm had the
> > ability to enumerate pci busses.
> >
> > On OpenBSD /dev/pci* is only read/writable by root.  /dev/drm* is
> > chowned after a user logs into a console.
> >
> > Yes that's correct. The principle is that the platform/kernel has a method
> of enumerating and providing basic information for the available devices.
> Note that there are multiple applications explicitly dropping OpenBSD
> support from their TODO because it lacks the ability [from unprivileged
> context].
> 
> We don't use filesystems for communicating with the kernel like linux
> > does so ioctls are really the best fit.  The loader parts used at the
> > moment use drm driver specific ioctls, hopefully a generic version of
> > those that can return the vid/pid, subids and function id numbers would
> > cover most of it.
> 
> Afaict retrieving the vendor/device ID et al is not a security concern
> (admittedly I'm not a security person) nor drm specific.
> 
> As-is one will end up with multiple implementations - one per subsystem
> leading to extra code and maintenance burden on both OpenBSD end and for
> apps who want to support the platform.
> 
> Hope that makes things clear and doesn't sound too ranty ;-)
> Emil

The drm functions in question ask for pci information by passing in
major and minor numbers of drm devices or in the case of
drmParsePciDeviceInfo bizzarely just "drm0", not sure why the
inconsistency there.  They aren't enumerating buses they are responding
based on information from drm sources.  So it's going to be drm not pci
ioctls.

The real problem is going to be in adding drm ioctls I'd have to convince
the linux kernel people to reserve numbers, people involved in libdrm
and people involved in OpenBSD.  Though the functions would then be
useable for systems beyond just those with sysfs if they implemented the
ioctls.

I had diffs from a few months ago to do drmGetMinorNameForFD based on
loader drm_get_device_name_for_fd, drmParsePciDeviceInfo based on 
drm_get_pci_id_for_fd and defaulting to DRM_BUS_PCI rather than an error
in drmParseSubsystemType.  I don't think there is a way to retrieve the
drmParsePciBusInfo data with the existing ioctls though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD

[Jonathan Gray]

On Wed, Oct 19, 2016 at 03:17:07PM +0100, Emil Velikov wrote:
> On 19 October 2016 at 14:16, Jonathan Gray <j...@jsg.id.au> wrote:
> > On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote:
> >> On 19 October 2016 at 01:05, Jonathan Gray <j...@jsg.id.au> wrote:
> >> > On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote:
> >> >> On 18 October 2016 at 00:58, Jonathan Gray <j...@jsg.id.au> wrote:
> >> >> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
> >> >> >> On 17 October 2016 at 16:39, Eric Engestrom 
> >> >> >> <eric.engest...@imgtec.com> wrote:
> >> >> >> > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote:
> >> >> >> >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote:
> >> >> >> >> > On 17 October 2016 at 10:53, Eric Engestrom 
> >> >> >> >> > <eric.engest...@imgtec.com> wrote:
> >> >> >> >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote:
> >> >> >> >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find
> >> >> >> >> > >> the highest major/minor version and open it in this case.
> >> >> >> >> > >>
> >> >> >> >> > >> Avoids '#error Unknown glapi provider for this platform' at 
> >> >> >> >> > >> build time.
> >> >> >> >> > >>
> >> >> >> >> > >> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> >> >> >> >> > >
> >> >> >> >> > > LGTM, and I guess the other *BSD will want the same since 
> >> >> >> >> > > 7a9c92d0 broke
> >> >> >> >> > > them too.
> >> >> >> >> > >
> >> >> >> >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did 
> >> >> >> >> > bump the
> >> >> >> >> > major when the ABI breaks due to 'internal' changes - think of
> >> >> >> >> > off_t/time_t on 32 vs 64bit systems and alike.
> >> >> >> >> >
> >> >> >> >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when 
> >> >> >> >> > in
> >> >> >> >> > comes to ABI, I believe. Don't quote me on that one ;-)
> >> >> >> >>
> >> >> >> >> OpenBSD tends to favour simplified interfaces over backwards 
> >> >> >> >> compatiblity
> >> >> >> >> and is more like a research system in that respect.  As the kernel
> >> >> >> >> and userland are one source tree ioctl compat largely doesn't 
> >> >> >> >> exist.
> >> >> >> >> System calls get deprecated and removed over the course of a few 
> >> >> >> >> releases.
> >> >> >> >> So we didn't go through the pain of duplicated systems calls for 
> >> >> >> >> off_t
> >> >> >> >> as mentioned, and don't go in for symbol versioning.  Just 
> >> >> >> >> major.minor
> >> >> >> >> library versioning, which is roughly symbol removals, major crank,
> >> >> >> >> symbol additions minor crank.
> >> >> >> >>
> >> >> >> >> I believe FreeBSD tends to go in for backwards compatibility more
> >> >> >> >> but am not familiar with the details.  They also have a different 
> >> >> >> >> ld.so.
> >> >> >> >>
> >> >> >> >> Perhaps an else case for 'libglapi.so.0' would be appropriate for 
> >> >> >> >> all
> >> >> >> >> the other various unices instead of the #error ?
> >> >> >> >
> >> >> >> > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might 
> >> >> >> > be a better,
> >> >> >> > to avoid the potentially huge list of every *BSD and other Unix:
> >> >> >> >
> >> >> >> Fwiw I've intentionally added the hunk since I was a bit lazy to 
> >> >> >> 

Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD

[Jonathan Gray]

On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote:
> On 19 October 2016 at 01:05, Jonathan Gray <j...@jsg.id.au> wrote:
> > On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote:
> >> On 18 October 2016 at 00:58, Jonathan Gray <j...@jsg.id.au> wrote:
> >> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
> >> >> On 17 October 2016 at 16:39, Eric Engestrom <eric.engest...@imgtec.com> 
> >> >> wrote:
> >> >> > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote:
> >> >> >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote:
> >> >> >> > On 17 October 2016 at 10:53, Eric Engestrom 
> >> >> >> > <eric.engest...@imgtec.com> wrote:
> >> >> >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote:
> >> >> >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find
> >> >> >> > >> the highest major/minor version and open it in this case.
> >> >> >> > >>
> >> >> >> > >> Avoids '#error Unknown glapi provider for this platform' at 
> >> >> >> > >> build time.
> >> >> >> > >>
> >> >> >> > >> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> >> >> >> > >
> >> >> >> > > LGTM, and I guess the other *BSD will want the same since 
> >> >> >> > > 7a9c92d0 broke
> >> >> >> > > them too.
> >> >> >> > >
> >> >> >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump 
> >> >> >> > the
> >> >> >> > major when the ABI breaks due to 'internal' changes - think of
> >> >> >> > off_t/time_t on 32 vs 64bit systems and alike.
> >> >> >> >
> >> >> >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when in
> >> >> >> > comes to ABI, I believe. Don't quote me on that one ;-)
> >> >> >>
> >> >> >> OpenBSD tends to favour simplified interfaces over backwards 
> >> >> >> compatiblity
> >> >> >> and is more like a research system in that respect.  As the kernel
> >> >> >> and userland are one source tree ioctl compat largely doesn't exist.
> >> >> >> System calls get deprecated and removed over the course of a few 
> >> >> >> releases.
> >> >> >> So we didn't go through the pain of duplicated systems calls for 
> >> >> >> off_t
> >> >> >> as mentioned, and don't go in for symbol versioning.  Just 
> >> >> >> major.minor
> >> >> >> library versioning, which is roughly symbol removals, major crank,
> >> >> >> symbol additions minor crank.
> >> >> >>
> >> >> >> I believe FreeBSD tends to go in for backwards compatibility more
> >> >> >> but am not familiar with the details.  They also have a different 
> >> >> >> ld.so.
> >> >> >>
> >> >> >> Perhaps an else case for 'libglapi.so.0' would be appropriate for all
> >> >> >> the other various unices instead of the #error ?
> >> >> >
> >> >> > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might be 
> >> >> > a better,
> >> >> > to avoid the potentially huge list of every *BSD and other Unix:
> >> >> >
> >> >> Fwiw I've intentionally added the hunk since I was a bit lazy to check
> >> >> if the BSD(s?)/Solaris/others have bumped the major locally. Having a
> >> >> closer look that's not the case, so indeed we can add revert to
> >> >> libglapi.so.0 in the else statement.
> >> >>
> >> >> Jonathan, how about we with the above instead ?
> >> >
> >> > At the moment OpenBSD has libglapi.so.0.2 for Mesa 11.2.2.
> >> > New versions of Mesa add new shared_dispatch_stub_* symbols,
> >> > which the minor would crank for.
> >> >
> >> Don't think we [intentionally] added any symbols for a long while.
> >
> > Comparing 11.2.2 libglapi and the latest Mesa I see:
> >
> > Dynamic export changes:
> > added:
> > shared_dispatch_stub_1323
> > shared_dispatch_stub_1324
> > shared_dispatch_stub_1325
> > shared_dispatch_stub_1326
> > shared_dispatch_stub_1327
> > shared_dispatch_stub_1328
> > shared_dispatch_stub_1329
> >
> > Perhaps this is unique to the non-tls dispatch case though.
> >
> Seems like it. Either way, the symbols are exported unintentionally,
> since they are not part of the glapi API and are not used outside of
> libglapi.so.
> 
> Any patch(es) to hide them will be gladly appreciated.

It seems only the arch specific glapi asm stubs get it right?

I manually extracted the libglapi from debian's Mesa 12.0.3 for amd64 and armhf
and the shared_dispatch_stub symbols show up with debian's armhf library (but 
not amd64).

http://ftp.au.debian.org/debian/pool/main/m/mesa/libglapi-mesa_12.0.3-1_armhf.deb

$ nm usr/lib/arm-linux-gnueabihf/libglapi.so.0.0.0 | fgrep ' T 
shared_dispatch_stub' | wc -l
1324
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD

[Jonathan Gray]

On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote:
> On 18 October 2016 at 00:58, Jonathan Gray <j...@jsg.id.au> wrote:
> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
> >> On 17 October 2016 at 16:39, Eric Engestrom <eric.engest...@imgtec.com> 
> >> wrote:
> >> > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote:
> >> >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote:
> >> >> > On 17 October 2016 at 10:53, Eric Engestrom 
> >> >> > <eric.engest...@imgtec.com> wrote:
> >> >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote:
> >> >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find
> >> >> > >> the highest major/minor version and open it in this case.
> >> >> > >>
> >> >> > >> Avoids '#error Unknown glapi provider for this platform' at build 
> >> >> > >> time.
> >> >> > >>
> >> >> > >> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> >> >> > >
> >> >> > > LGTM, and I guess the other *BSD will want the same since 7a9c92d0 
> >> >> > > broke
> >> >> > > them too.
> >> >> > >
> >> >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump the
> >> >> > major when the ABI breaks due to 'internal' changes - think of
> >> >> > off_t/time_t on 32 vs 64bit systems and alike.
> >> >> >
> >> >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when in
> >> >> > comes to ABI, I believe. Don't quote me on that one ;-)
> >> >>
> >> >> OpenBSD tends to favour simplified interfaces over backwards 
> >> >> compatiblity
> >> >> and is more like a research system in that respect.  As the kernel
> >> >> and userland are one source tree ioctl compat largely doesn't exist.
> >> >> System calls get deprecated and removed over the course of a few 
> >> >> releases.
> >> >> So we didn't go through the pain of duplicated systems calls for off_t
> >> >> as mentioned, and don't go in for symbol versioning.  Just major.minor
> >> >> library versioning, which is roughly symbol removals, major crank,
> >> >> symbol additions minor crank.
> >> >>
> >> >> I believe FreeBSD tends to go in for backwards compatibility more
> >> >> but am not familiar with the details.  They also have a different ld.so.
> >> >>
> >> >> Perhaps an else case for 'libglapi.so.0' would be appropriate for all
> >> >> the other various unices instead of the #error ?
> >> >
> >> > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might be a 
> >> > better,
> >> > to avoid the potentially huge list of every *BSD and other Unix:
> >> >
> >> Fwiw I've intentionally added the hunk since I was a bit lazy to check
> >> if the BSD(s?)/Solaris/others have bumped the major locally. Having a
> >> closer look that's not the case, so indeed we can add revert to
> >> libglapi.so.0 in the else statement.
> >>
> >> Jonathan, how about we with the above instead ?
> >
> > At the moment OpenBSD has libglapi.so.0.2 for Mesa 11.2.2.
> > New versions of Mesa add new shared_dispatch_stub_* symbols,
> > which the minor would crank for.
> >
> Don't think we [intentionally] added any symbols for a long while.

Comparing 11.2.2 libglapi and the latest Mesa I see:

Dynamic export changes:
added:
shared_dispatch_stub_1323
shared_dispatch_stub_1324
shared_dispatch_stub_1325
shared_dispatch_stub_1326
shared_dispatch_stub_1327
shared_dispatch_stub_1328
shared_dispatch_stub_1329

Perhaps this is unique to the non-tls dispatch case though.

> 
> > I'd prefer the diff I mailed for OpenBSD for if the major version
> > should crank for some reason.
> Let's worry about that if/when it happens ?

sure

> 
> Emil
> /me lands the rest of the patches

thankS
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD

[Jonathan Gray]

On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote:
> On 17 October 2016 at 16:39, Eric Engestrom <eric.engest...@imgtec.com> wrote:
> > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote:
> >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote:
> >> > On 17 October 2016 at 10:53, Eric Engestrom <eric.engest...@imgtec.com> 
> >> > wrote:
> >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote:
> >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find
> >> > >> the highest major/minor version and open it in this case.
> >> > >>
> >> > >> Avoids '#error Unknown glapi provider for this platform' at build 
> >> > >> time.
> >> > >>
> >> > >> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> >> > >
> >> > > LGTM, and I guess the other *BSD will want the same since 7a9c92d0 
> >> > > broke
> >> > > them too.
> >> > >
> >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump the
> >> > major when the ABI breaks due to 'internal' changes - think of
> >> > off_t/time_t on 32 vs 64bit systems and alike.
> >> >
> >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when in
> >> > comes to ABI, I believe. Don't quote me on that one ;-)
> >>
> >> OpenBSD tends to favour simplified interfaces over backwards compatiblity
> >> and is more like a research system in that respect.  As the kernel
> >> and userland are one source tree ioctl compat largely doesn't exist.
> >> System calls get deprecated and removed over the course of a few releases.
> >> So we didn't go through the pain of duplicated systems calls for off_t
> >> as mentioned, and don't go in for symbol versioning.  Just major.minor
> >> library versioning, which is roughly symbol removals, major crank,
> >> symbol additions minor crank.
> >>
> >> I believe FreeBSD tends to go in for backwards compatibility more
> >> but am not familiar with the details.  They also have a different ld.so.
> >>
> >> Perhaps an else case for 'libglapi.so.0' would be appropriate for all
> >> the other various unices instead of the #error ?
> >
> > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might be a 
> > better,
> > to avoid the potentially huge list of every *BSD and other Unix:
> >
> Fwiw I've intentionally added the hunk since I was a bit lazy to check
> if the BSD(s?)/Solaris/others have bumped the major locally. Having a
> closer look that's not the case, so indeed we can add revert to
> libglapi.so.0 in the else statement.
> 
> Jonathan, how about we with the above instead ?

At the moment OpenBSD has libglapi.so.0.2 for Mesa 11.2.2.
New versions of Mesa add new shared_dispatch_stub_* symbols,
which the minor would crank for.

I'd prefer the diff I mailed for OpenBSD for if the major version
should crank for some reason.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD

[Jonathan Gray]

On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote:
> On 17 October 2016 at 10:53, Eric Engestrom <eric.engest...@imgtec.com> wrote:
> > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote:
> >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find
> >> the highest major/minor version and open it in this case.
> >>
> >> Avoids '#error Unknown glapi provider for this platform' at build time.
> >>
> >> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> >
> > LGTM, and I guess the other *BSD will want the same since 7a9c92d0 broke
> > them too.
> >
> I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump the
> major when the ABI breaks due to 'internal' changes - think of
> off_t/time_t on 32 vs 64bit systems and alike.
> 
> Unlike Linux kernel/distros, BSDs tend to be more relaxed when in
> comes to ABI, I believe. Don't quote me on that one ;-)

OpenBSD tends to favour simplified interfaces over backwards compatiblity
and is more like a research system in that respect.  As the kernel
and userland are one source tree ioctl compat largely doesn't exist.
System calls get deprecated and removed over the course of a few releases.
So we didn't go through the pain of duplicated systems calls for off_t
as mentioned, and don't go in for symbol versioning.  Just major.minor
library versioning, which is roughly symbol removals, major crank,
symbol additions minor crank.

I believe FreeBSD tends to go in for backwards compatibility more
but am not familiar with the details.  They also have a different ld.so.

Perhaps an else case for 'libglapi.so.0' would be appropriate for all
the other various unices instead of the #error ?

> 
> > Fixes: 7a9c92d071d010066349 ("egl/dri2: non-shared glapi cleanups")
> > Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
> >
> > Side note, I don't understand why we hardcode the version everywhere
> > (except Android). I can see it's been like that since that code was
> > added nearly 6 years ago (218381d9), but I couldn't find an explanation
> > in the logs, or any mention of it in the thread I found [1].
> > Emil, do you know?
> >
> The ABI must be stable. Since a) we (and linux distros in general)
> have the greater flexibility to "mix and match" components and b)
> glapi is/was used by xserver as well, the initial goal was that the
> ABI should not break, ever. See some the src/mapi changes by Brian
> Paul, which rework the nop calls due to different calling convention
> and stack corruption on Windows and the follow up fix to keep those
> Windows only and stable for everyone else
> be71bbfaa2ad201b570b56847a13328fc359d0ee.
> 
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] genxml: add generated headers to EXTRA_DIST

[Jonathan Gray]

On Sun, Oct 16, 2016 at 11:08:42PM +1100, Jonathan Gray wrote:
> Building the Mesa 12.0.3 distfile failed on a system without python
> as generated files were not included in the distfile.
> 
> Cc: "12.0" <mesa-sta...@lists.freedesktop.org>
> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> ---
>  src/intel/Makefile.genxml.am | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
> index 39f579c..2df223a 100644
> --- a/src/intel/Makefile.genxml.am
> +++ b/src/intel/Makefile.genxml.am
> @@ -23,6 +23,10 @@ BUILT_SOURCES += \
>   $(GENXML_GENERATED_FILES) \
>   $(AUBINATOR_GENERATED_FILES)
>  
> +EXTRA_DIST += \
> + $(GENXML_GENERATED_FILES) \
> + $(AUBINATOR_GENERATED_FILES)
> +
>  SUFFIXES = _pack.h _xml.h .xml
>  
>  $(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
> -- 
> 2.9.3

The makefiles are different on the 12.0 branch and there is no
aubinator.  Here is a patch against the 12.0 branch:

diff --git a/src/intel/genxml/Makefile.am b/src/intel/genxml/Makefile.am
index f98cf78..32f5ace 100644
--- a/src/intel/genxml/Makefile.am
+++ b/src/intel/genxml/Makefile.am
@@ -37,6 +37,7 @@ endif
 CLEANFILES = $(BUILT_SOURCES)
 
 EXTRA_DIST = \
+   $(GENXML_GENERATED_FILES) \
gen6.xml \
gen7.xml \
gen75.xml \
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: automake: include mesa_glinterop.h in distfile

[Jonathan Gray]

Add mesa_glinterop.h to the list of headers that will get included
in the distfile as it is required to build Mesa itself.

Corrects a regression introduced in a89faa2022fd995af2019c886b152b49a01f9392.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 17c8798..b63d135 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -131,7 +131,8 @@ SUBDIRS += gallium
 endif
 
 EXTRA_DIST = \
-   getopt hgl SConscript
+   getopt hgl SConscript \
+   $(top_srcdir)/include/GL/mesa_glinterop.h
 
 AM_CFLAGS = $(VISIBILITY_CFLAGS)
 AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] genxml: add generated headers to EXTRA_DIST

[Jonathan Gray]

Building the Mesa 12.0.3 distfile failed on a system without python
as generated files were not included in the distfile.

Cc: "12.0" <mesa-sta...@lists.freedesktop.org>
Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/intel/Makefile.genxml.am | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index 39f579c..2df223a 100644
--- a/src/intel/Makefile.genxml.am
+++ b/src/intel/Makefile.genxml.am
@@ -23,6 +23,10 @@ BUILT_SOURCES += \
$(GENXML_GENERATED_FILES) \
$(AUBINATOR_GENERATED_FILES)
 
+EXTRA_DIST += \
+   $(GENXML_GENERATED_FILES) \
+   $(AUBINATOR_GENERATED_FILES)
+
 SUFFIXES = _pack.h _xml.h .xml
 
 $(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] egl: remove docs directory from EXTRA_DIST

[Jonathan Gray]

The egl docs directory no longer exists as of
88b5c36fe1a1546bf633ee161a6715efc593acbd.

Remove it from EXTRA_DIST to unbreak 'make dist'

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/egl/Makefile.am | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index 95ee6cc..304b0d3 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -132,6 +132,5 @@ EXTRA_DIST = \
egl-symbols-check \
SConscript \
drivers/haiku \
-   docs \
main/egl.def \
main/README.txt
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] genxml: avoid using a GNU make pattern rule

[Jonathan Gray]

% pattern rules are a GNU extension.  Convert the use of one to a
inference rule to allow this to build on OpenBSD.

This is a related change to the one made in
e3d43dc5eae5271e2c87bab702aa7409d3dd0b23

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/intel/Makefile.genxml.am | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index 519f30e..39f579c 100644
--- a/src/intel/Makefile.genxml.am
+++ b/src/intel/Makefile.genxml.am
@@ -34,7 +34,10 @@ $(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
 # xxd generates variable names based on the path of the input file. We
 # prefer to generate our own name here, so it doesn't vary from
 # in/out-of-tree builds.
-%_xml.h:  %.xml Makefile
+
+$(GENXML_GENERATED_FILES): Makefile
+
+.xml_xml.h:
$(MKDIR_GEN)
$(AM_V_GEN) echo -n "static const uint8_t " > $@; \
echo "$(@F)_xml[] = {" | sed -e 's,_xml.h,,' >> $@; \
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD

[Jonathan Gray]

On OpenBSD try to dlopen 'libglapi.so', ld.so will find
the highest major/minor version and open it in this case.

Avoids '#error Unknown glapi provider for this platform' at build time.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/egl/drivers/dri2/egl_dri2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 8785e31..9655a49 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2802,7 +2802,7 @@ static EGLBoolean
 dri2_load(_EGLDriver *drv)
 {
struct dri2_egl_driver *dri2_drv = dri2_egl_driver(drv);
-#ifdef HAVE_ANDROID_PLATFORM
+#if defined(HAVE_ANDROID_PLATFORM) || defined(__OpenBSD__)
const char *libname = "libglapi.so";
 #elif defined(__APPLE__)
const char *libname = "libglapi.0.dylib";
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/16] loader: slim down loader_get_pci_id_for_fd implementation(s)

[Jonathan Gray]

On Tue, Oct 11, 2016 at 07:31:46PM +0100, Emil Velikov wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
> 
> Currently mesa has three code paths in the loader - libudev, manual
> sysfs and drm ioctl one.
> 
> Considering the issues we had with libudev - strip those down in favour
> of the libdrm drm device API. The latter can be implemented in any way
> depending on the platform and can be reused by others.
> 
> Cc: Jonathan Gray <j...@jsg.id.au>
> Cc: Jean-S??bastien P??dron <dumbb...@freebsd.org>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
> Jonathan, Jean-S??bastien I believe I've prodded you guys for a *BSD
> implementation of the drm*Device API a while back. With this commit
> you'll be 'forced' to prep some ;-)

It has been a while since I looked into that.  The design seemed to
assume that the user running code that called into libdrm had the
ability to enumerate pci busses.

On OpenBSD /dev/pci* is only read/writable by root.  /dev/drm* is
chowned after a user logs into a console.

We don't use filesystems for communicating with the kernel like linux
does so ioctls are really the best fit.  The loader parts used at the
moment use drm driver specific ioctls, hopefully a generic version of
those that can return the vid/pid, subids and function id numbers would
cover most of it.

> 
> About the implementation itself feel free to use libudev/equivalent (we
> cannot do so on Linux, since due to fun interactions with Steam's one)
> or any other means available on your platform. Fwiw I would strongly
> suggest _against_ adding DRM specific ioctls just for this purpose but
> at the end of the day it's your code/userbase.
> 
> On the FreeBSD/DragonFly side this means that you no londer require a
> handful of patches for mesa, which is always a plus.
> ---
>  src/loader/loader.c | 172 
> +---
>  1 file changed, 16 insertions(+), 156 deletions(-)
> 
> diff --git a/src/loader/loader.c b/src/loader/loader.c
> index 3e60e4c..41ea016 100644
> --- a/src/loader/loader.c
> +++ b/src/loader/loader.c
> @@ -204,57 +204,6 @@ udev_device_new_from_fd(struct udev *udev, int fd)
> return device;
>  }
>  
> -static int
> -libudev_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
> -{
> -   struct udev *udev = NULL;
> -   struct udev_device *device = NULL, *parent;
> -   const char *pci_id;
> -   UDEV_SYMBOL(struct udev *, udev_new, (void));
> -   UDEV_SYMBOL(struct udev_device *, udev_device_get_parent,
> -   (struct udev_device *));
> -   UDEV_SYMBOL(const char *, udev_device_get_property_value,
> -   (struct udev_device *, const char *));
> -   UDEV_SYMBOL(struct udev_device *, udev_device_unref,
> -   (struct udev_device *));
> -   UDEV_SYMBOL(struct udev *, udev_unref, (struct udev *));
> -
> -   *chip_id = -1;
> -
> -   if (dlsym_failed)
> -  return 0;
> -
> -   udev = udev_new();
> -   device = udev_device_new_from_fd(udev, fd);
> -   if (!device)
> -  goto out;
> -
> -   parent = udev_device_get_parent(device);
> -   if (parent == NULL) {
> -  log_(_LOADER_WARNING, "MESA-LOADER: could not get parent device\n");
> -  goto out;
> -   }
> -
> -   pci_id = udev_device_get_property_value(parent, "PCI_ID");
> -   if (pci_id == NULL) {
> -  log_(_LOADER_INFO, "MESA-LOADER: no PCI ID\n");
> -  *chip_id = -1;
> -  goto out;
> -   } else if (sscanf(pci_id, "%x:%x", vendor_id, chip_id) != 2) {
> -  log_(_LOADER_WARNING, "MESA-LOADER: malformed PCI ID\n");
> -  *chip_id = -1;
> -  goto out;
> -   }
> -
> -out:
> -   if (device)
> -  udev_device_unref(device);
> -   if (udev)
> -  udev_unref(udev);
> -
> -   return (*chip_id >= 0);
> -}
> -
>  static char *
>  get_render_node_from_id_path_tag(struct udev *udev,
>   char *id_path_tag,
> @@ -471,113 +420,32 @@ dev_node_from_fd(int fd, unsigned int *maj, unsigned 
> int *min)
>  }
>  #endif
>  
> -#if defined(HAVE_SYSFS)
> -static int
> -sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
> -{
> -   unsigned int maj, min;
> -   FILE *f;
> -   char buf[0x40];
> -
> -   if (dev_node_from_fd(fd, , ) < 0) {
> -  *chip_id = -1;
> -  return 0;
> -   }
> -
> -   snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/vendor", maj, min);
> -   if (!(f = fopen(buf, "r"))) {
> -  *chip_id = -1;
> -  return 0;
> -   }
> -   if (fscanf(f, "%x", vendor_id) != 1) {
> -  *chip_id = -1;
> -  fclose(f);
>

Re: [Mesa-dev] [PATCH 1/2] aubinator: rework print_help()

[Jonathan Gray]

On Mon, Sep 12, 2016 at 12:59:11PM +0100, Emil Velikov wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
> 
> Rather than using platform specific methods to retrieve the program
> name pass it explicitly. The function is called directly from main().
> 
> Similarly - basename comes in two versions POSIX (can modify string,
> always pass a copy) and GNU (never modifies the string).
> 
> Just printout the complete program name, esp. since the program is not
> meant to be installed, thus using $basename is unlikely to work, not to
> mention it is misleading.
> 
> Cc: Jonathan Gray <j...@jsg.id.au>
> Cc: Timothy Arceri <timothy.arc...@collabora.com>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>

Looks good and builds here.

Reviewed-by: Jonathan Gray <j...@jsg.id.au>

> ---
>  src/intel/tools/aubinator.c | 17 +
>  1 file changed, 5 insertions(+), 12 deletions(-)
> 
> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> index fe1f369..9d29b68 100644
> --- a/src/intel/tools/aubinator.c
> +++ b/src/intel/tools/aubinator.c
> @@ -30,7 +30,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -1012,14 +1011,8 @@ setup_pager(void)
>  }
>  
>  static void
> -print_help(FILE *file)
> +print_help(const char *progname, FILE *file)
>  {
> -   const char *progname;
> -#if defined(__GLIBC__) || defined(__CYGWIN__)
> -   progname = program_invocation_short_name;
> -#else
> -   progname = getprogname();
> -#endif
> fprintf(file,
> "Usage: %s [OPTION]... FILE\n"
> "Decode aub file contents.\n\n"
> @@ -1031,7 +1024,7 @@ print_help(FILE *file)
> "if omitted), 'always', or 'never'\n"
> "  --no-pager  don't launch pager\n"
> "  --no-offsetsdon't print instruction offsets\n",
> -   basename(progname));
> +   progname);
>  }
>  
>  static bool
> @@ -1062,7 +1055,7 @@ int main(int argc, char *argv[])
> char gen_file[256], gen_val[24];
>  
> if (argc == 1) {
> -  print_help(stderr);
> +  print_help(argv[0], stderr);
>exit(EXIT_FAILURE);
> }
>  
> @@ -1094,7 +1087,7 @@ int main(int argc, char *argv[])
>  exit(EXIT_FAILURE);
>   }
>} else if (strcmp(argv[i], "--help") == 0) {
> - print_help(stdout);
> + print_help(argv[0], stdout);
>   exit(EXIT_SUCCESS);
>} else {
>   if (argv[i][0] == '-') {
> @@ -1174,7 +1167,7 @@ int main(int argc, char *argv[])
> disasm = gen_disasm_create(pci_id);
>  
> if (argv[i] == NULL) {
> -   print_help(stderr);
> +   print_help(argv[0], stderr);
> exit(EXIT_FAILURE);
> } else {
> file = aub_file_open(argv[i]);
> -- 
> 2.9.3
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] aubinator: only use program_invocation_short_name with glibc/cygwin

[Jonathan Gray]

On Mon, Sep 12, 2016 at 09:28:58AM +1000, Timothy Arceri wrote:
> On Thu, 2016-09-08 at 18:39 +0100, Emil Velikov wrote:
> > On 1 September 2016 at 18:12, Jonathan Gray <j...@jsg.id.au> wrote:
> > > 
> > > program_invocation_short_name is a gnu extension.Limit use of it
> > > to glibc and cygwin and otherwise use getprogname() which is
> > > available
> > > on BSD and OS X.
> > > 
> > > Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> > > ---
> > > ??src/intel/tools/aubinator.c | 8 +++-
> > > ??1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/src/intel/tools/aubinator.c
> > > b/src/intel/tools/aubinator.c
> > > index df84469..fe1f369 100644
> > > --- a/src/intel/tools/aubinator.c
> > > +++ b/src/intel/tools/aubinator.c
> > > @@ -1014,6 +1014,12 @@ setup_pager(void)
> > > ??static void
> > > ??print_help(FILE *file)
> > > ??{
> > > +??const char *progname;
> > > +#if defined(__GLIBC__) || defined(__CYGWIN__)
> > > +??progname = program_invocation_short_name;
> > > +#else
> > > +??progname = getprogname();
> > > +#endif
> > We could really fold the ~5 hunks somehow. Then again it shouldn't
> > block this fix from getting it.
> > 
> > R-b and pushed the series. Thanks !
> > Emil
> 
> This is causing a warning in GCC:
> 
> aubinator.c: In function ???print_help???:
> aubinator.c:1034:21: warning: passing argument 1 of ???__xpg_basename???
> discards ???const??? qualifier from pointer target type [-Wdiscarded-
> qualifiers]
> basename(progname));
> ??^~~~
> In file included from aubinator.c:33:0:
> /usr/include/libgen.h:34:14: note: expected ???char *??? but argument is of
> type ???const char *???
> ??extern char *__xpg_basename (char *__path) __THROW;
> ^~

getprogname() returns const, it seems odd that program_invocation_short_name
would not be as well.

Note that the gallium code in src/gallium/auxiliary/os/os_process.c
os_get_process_name() also stores program_invocation_short_name in
"const char *".
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Disable the code that allocates W|X memory on OpenBSD

[Jonathan Gray]

On Thu, Sep 08, 2016 at 06:57:44PM +0100, Emil Velikov wrote:
> On 1 September 2016 at 18:23, Jonathan Gray <j...@jsg.id.au> wrote:
> > OpenBSD now has strict W^X enforcement.  Processes that violate
> > the policy get killed by the kernel.  Don't attempt to use
> > executable memory on OpenBSD to avoid this.
> >
> > Patch from Mark Kettenis.
> >
> 
> > --- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> > +++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> > @@ -69,6 +69,16 @@ static struct mem_block *exec_heap = NULL;
> >  static unsigned char *exec_mem = NULL;
> >
> >
> > +#ifdef __OpenBSD__
> > +
> > +static int
> > +init_heap(void)
> > +{
> > +   return 0;
> > +}
> Afaict this is equivalent to using the #else path in translate_see.c.
> In general I'm wondering if we can/should not have a configure toggle
> for this. Then again please look below.
> 
> 
> > --- a/src/mapi/u_execmem.c
> > +++ b/src/mapi/u_execmem.c
> > @@ -45,8 +45,15 @@ static unsigned int head = 0;
> >
> >  static unsigned char *exec_mem = (unsigned char *)0;
> >
> > +#if defined(__OpenBSD__)
> >
> > -#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || 
> > defined(__sun) || defined(__HAIKU__)
> > +static int
> > +init_map(void)
> > +{
> > +  return 0;
> > +}
> > +
> And this one to --disable-glx-tls and/or --disable-asm. Which reminds
> me of - have you guys tried enabling either/both of them. Has there
> been (m)any issues ?
> 
> For a long while the intent has been to use --enable-glx-tls by
> default and kill off the other codepaths. But with the write xor
> execute policy, it's going to be (close to) impossible.

Full tls support is not in the OpenBSD tree currently, though the
remaining parts were being looked at including enabling tls with Mesa
last week.  I'm not sure what state that work is in currently.

> Have you guys considered a way to disable the restriction for usecases
> that need the behaviour ?

The limited exceptions involve flagging binaries and having to mount
the filesystem containing them with a flag.  This is mostly a temporary
measure as I understand it and libraries especially should not be creating
W|X mappings.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] mesa: bump required GCC version to 4.8.0

[Jonathan Gray]

On Wed, Sep 07, 2016 at 11:52:39PM +1000, Timothy Arceri wrote:
> On Wed, 2016-09-07 at 19:26 +1000, Jonathan Gray wrote:
> > LLVM was imported yes, but the integration of it has only
> > started around the same time and it is not enabled by default yet.
> > And it was only imported around two days or so ago.
> > 
> 
> Which means its a good time to start a discussion on what the inclusion means
> for Mesa :)
> 
> > And LLVM does not support all the architectures OpenBSD builds Mesa
> > on.
> > 
> > Can you point to something specific that needs a newer GCC version?
> > Do you want to target c++11 or the like?
> 
> We have discussed specific features in the past. At this point its move about
> giving developers the freedom to use any new features they wish. And
> ultimately the ability to bump the required version again in future.
> 
> It seems you are talking about the possibly of never switching to clang for
> building Mesa and sticking with gcc 4.2 for years to come. There is also the
> issue as I understand it that your gcc 4.2 is not really gcc 4.2, as you say
> features have been back ported to support Mesa so its possible that Mesa would
> not even build for a normal gcc 4.2 build and our build requirements act more
> as a restriction on developers using features rather than enforcing a building
> requirement.??

You seem to have misinterpreted.  The current plan is to switch
some architectures to clang in the future.

If your patch gets committed to Mesa I'll have to either revert it locally
or stop updating Mesa in the short term.  Ideally configure would be a bit more
intelligent and test functionality rather than a version number.

I don't have a full list of changes made to acommodate Mesa,
here are some found with a quick search,  I believe FreeBSD has
also adopted many of these.

- binary integer constants (gnu extension clang also has)
http://marc.info/?l=openbsd-cvs=137290441510098=2
- support for \<word\> in regcomp (sysv/gnu extension)
http://marc.info/?l=openbsd-cvs=141019114911164=2

- named initialisers for anonymous structs/unions (required by C11)
http://marc.info/?l=openbsd-cvs=146244074408249=2

alpha ICE fix with __sync builtins
http://marc.info/?l=openbsd-cvs=145663405924066=2
i386 fix __sync_val_compare_and_swap_8() for -fPIC
http://marc.info/?l=openbsd-cvs=144898317222499=2

The sync builtins are assumed to be present on architectures where
they are not available at the instruction level.  GCC was modified
to additionally provide/expand these on at least mips64 and alpha.

mips bfd -Bsymbolic fix
http://marc.info/?l=openbsd-cvs=144856828610069=2

enum attribute handling fix
http://marc.info/?l=openbsd-cvs=144421363218215=2

recognise 'F'/'f' suffix for indent (cat is now used if gnu indent not found)
http://marc.info/?l=openbsd-cvs=142190494629047=2


> It is my feeling that we should be bumping the gcc requirements for Mesa based
> on the actual gcc project. Freezing the limit at the version of a forked gcc
> variant, and using features from higher versions that have been back ported to
> that fork seems backwards to me.
> 
> To me the current situation seems??untenable, besides the issues with having a
> minimum version that won't actually build Mesa I don't believe we should be
> forced to worry about ancient compilers indefinitely??due to the 
> decisions??of a
> singe distro. In my opinion we should bump the version and let OpenBSD resolve
> any issues however it sees fit (patch gcc/mesa, freeze mesa, etc). Others may
> feel differently.

There are already various local patches required to build Mesa, many pending
review.  Another could be added.

Subportions of the Mesa tree such as those that aren't built by visual studio
or recently merged projects such as the intel vulkan support already
assume the compiler is a new version of gcc in my experience.  It seems
anonymous structs/unions turned up everywhere when redhat declared the rhel
version which didn't have them eol for example.

Where as the vulkan code seems to directly depend on linux syscalls for
at least futexes and memfd (checks for which should be added to configure
as well, currently the build errors out).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] mesa: bump required GCC version to 4.8.0

[Jonathan Gray]

LLVM was imported yes, but the integration of it has only
started around the same time and it is not enabled by default yet.
And it was only imported around two days or so ago.

And LLVM does not support all the architectures OpenBSD builds Mesa
on.

Can you point to something specific that needs a newer GCC version?
Do you want to target c++11 or the like?

We have patched the GCC included in the base tree multiple times
to support Mesa and could possibly do so again if you mention
specifics.

On Wed, Sep 07, 2016 at 02:28:16PM +1000, Timothy Arceri wrote:
> The last time this was bumped we settled on 4.2.0 because OpenBSD
> wasn't shipping anything greater than 4.2.1 (as that was the last
> GPLv2 licensed version) however they have now imported llvm to
> there base repo.
> 
> As far as I can tell the oldest distro still using a current version
> of Mesa is Red Hat Enterprise Linux 6 which ships with 4.4.7. However
> Dave reported that they build Mesa with GCC 4.8.
> 
> Cc: Jonathan Gray <j...@jsg.id.au>
> ---
>  configure.ac | 18 +++---
>  include/c99_compat.h | 17 +++--
>  2 files changed, 10 insertions(+), 25 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index a413a3a..5128fc4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -171,7 +171,6 @@ AC_MSG_RESULT([$acv_mesa_CLANG])
>  dnl If we're using GCC, make sure that it is at least version 4.2.0.  Older
>  dnl versions are explictly not supported.
>  GEN_ASM_OFFSETS=no
> -USE_GNU99=no
>  if test "x$GCC" = xyes -a "x$acv_mesa_CLANG" = xno; then
>  AC_MSG_CHECKING([whether gcc version is sufficient])
>  major=0
> @@ -183,16 +182,13 @@ if test "x$GCC" = xyes -a "x$acv_mesa_CLANG" = xno; then
>  GCC_VERSION_MINOR=`echo $GCC_VERSION | cut -d. -f2`
>  fi
>  
> -if test $GCC_VERSION_MAJOR -lt 4 -o $GCC_VERSION_MAJOR -eq 4 -a 
> $GCC_VERSION_MINOR -lt 2 ; then
> +if test $GCC_VERSION_MAJOR -lt 4 -o $GCC_VERSION_MAJOR -eq 4 -a 
> $GCC_VERSION_MINOR -lt 8 ; then
>  AC_MSG_RESULT([no])
> -AC_MSG_ERROR([If using GCC, version 4.2.0 or later is required.])
> +AC_MSG_ERROR([If using GCC, version 4.8.0 or later is required.])
>  else
>  AC_MSG_RESULT([yes])
>  fi
>  
> -if test $GCC_VERSION_MAJOR -lt 4 -o $GCC_VERSION_MAJOR -eq 4 -a 
> $GCC_VERSION_MINOR -lt 6 ; then
> -USE_GNU99=yes
> -fi
>  if test "x$cross_compiling" = xyes; then
>  GEN_ASM_OFFSETS=yes
>  fi
> @@ -269,12 +265,7 @@ AM_CONDITIONAL(HAVE_ANDROID, test "x$android" = xyes)
>  dnl Add flags for gcc and g++
>  if test "x$GCC" = xyes; then
>  CFLAGS="$CFLAGS -Wall"
> -
> -if test "x$USE_GNU99" = xyes; then
> - CFLAGS="$CFLAGS -std=gnu99"
> -else
> - CFLAGS="$CFLAGS -std=c99"
> -fi
> +CFLAGS="$CFLAGS -std=c99"
>  
>  # Enable -Werror=implicit-function-declaration and
>  # -Werror=missing-prototypes, if available, or otherwise, just
> @@ -401,9 +392,6 @@ AC_MSG_CHECKING(whether gcc supports -mpower8-vector)
>  save_CFLAGS=$CFLAGS
>  CFLAGS="$PWR8_CFLAGS $CFLAGS"
>  AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
> -#if defined(__GNUC__) && (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 
> 8))
> -#error "Need GCC >= 4.8 for sane POWER8 support"
> -#endif
>  #include 
>  int main () {
>  vector unsigned char r;
> diff --git a/include/c99_compat.h b/include/c99_compat.h
> index 24e96e0..d76171c 100644
> --- a/include/c99_compat.h
> +++ b/include/c99_compat.h
> @@ -145,8 +145,8 @@ test_c99_compat_h(const void * restrict a,
>  #  endif
>  
>  #  ifdef __GNUC__
> -#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 2)
> -#  error "GCC version 4.2 or higher required"
> +#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 8)
> +#  error "GCC version 4.8 or higher required"
>  #endif
>  
>   /* https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Other-Builtins.html */
> @@ -164,15 +164,12 @@ test_c99_compat_h(const void * restrict a,
>  #define HAVE_FUNC_ATTRIBUTE_FORMAT 1
>  #define HAVE_FUNC_ATTRIBUTE_PACKED 1
>  
> -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3)
> -   /* https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Other-Builtins.html */
> -#  define HAVE___BUILTIN_BSWAP32 1
> -#  define HAVE___BUILTIN_BSWAP64 1
> -#endif
> + /* https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Other-Builtins.html */
> +#define HAVE___BUILTIN_BSWAP32 1
> +#define HAVE___BUILTIN_BSWAP64 1
>  
> -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5)
> -#  define HAVE___BUILTIN_UNREACHABLE 1
> -#endif
> + /* GCC 4.5 */
> +#define HAVE___BUILTIN_UNREACHABLE 1
>  
>  #  endif /* __GNUC__ */
>  
> -- 
> 2.7.4
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] aubinator: include libgen.h for basename(3)

[Jonathan Gray]

Include libgen.h for basename as required by posix.
The definition is not found on at least OpenBSD otherwise.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/intel/tools/aubinator.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 66107711..df84469 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Disable the code that allocates W|X memory on OpenBSD

[Jonathan Gray]

OpenBSD now has strict W^X enforcement.  Processes that violate
the policy get killed by the kernel.  Don't attempt to use
executable memory on OpenBSD to avoid this.

Patch from Mark Kettenis.

Cc: 11.2 12.0 <mesa-sta...@lists.freedesktop.org>
Signed-off-by: Mark Kettenis <kette...@openbsd.org>
Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/gallium/auxiliary/rtasm/rtasm_execmem.c | 12 
 src/mapi/u_execmem.c|  9 -
 src/mesa/main/execmem.c | 15 ++-
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/rtasm/rtasm_execmem.c 
b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
index f7e605e..edbb459 100644
--- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
+++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
@@ -69,6 +69,16 @@ static struct mem_block *exec_heap = NULL;
 static unsigned char *exec_mem = NULL;
 
 
+#ifdef __OpenBSD__
+
+static int
+init_heap(void)
+{
+   return 0;
+}
+
+#else
+
 static int
 init_heap(void)
 {
@@ -83,6 +93,8 @@ init_heap(void)
return (exec_mem != MAP_FAILED);
 }
 
+#endif
+
 
 void *
 rtasm_exec_malloc(size_t size)
diff --git a/src/mapi/u_execmem.c b/src/mapi/u_execmem.c
index 89d5c1d..3af9d0a 100644
--- a/src/mapi/u_execmem.c
+++ b/src/mapi/u_execmem.c
@@ -45,8 +45,15 @@ static unsigned int head = 0;
 
 static unsigned char *exec_mem = (unsigned char *)0;
 
+#if defined(__OpenBSD__)
 
-#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || 
defined(__sun) || defined(__HAIKU__)
+static int
+init_map(void)
+{
+  return 0;
+}
+
+#elif defined(__linux__) || defined(_NetBSD__) || defined(__sun) || 
defined(__HAIKU__)
 
 #include 
 #include 
diff --git a/src/mesa/main/execmem.c b/src/mesa/main/execmem.c
index 3a13385..87e4a38 100644
--- a/src/mesa/main/execmem.c
+++ b/src/mesa/main/execmem.c
@@ -36,7 +36,20 @@
 
 
 
-#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || 
defined(__sun) || defined(__HAIKU__)
+#if defined(__OpenBSD__)
+
+void *
+_mesa_exec_malloc(GLuint size)
+{
+   return NULL;
+}
+
+void
+_mesa_exec_free(void *addr)
+{
+}
+
+#elif defined(__linux__) || defined(_NetBSD__) || defined(__sun) || 
defined(__HAIKU__)
 
 /*
  * Allocate a large block of memory which can hold code then dole it out
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] aubinator: only use program_invocation_short_name with glibc/cygwin

[Jonathan Gray]

program_invocation_short_name is a gnu extension.  Limit use of it
to glibc and cygwin and otherwise use getprogname() which is available
on BSD and OS X.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/intel/tools/aubinator.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index df84469..fe1f369 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -1014,6 +1014,12 @@ setup_pager(void)
 static void
 print_help(FILE *file)
 {
+   const char *progname;
+#if defined(__GLIBC__) || defined(__CYGWIN__)
+   progname = program_invocation_short_name;
+#else
+   progname = getprogname();
+#endif
fprintf(file,
"Usage: %s [OPTION]... FILE\n"
"Decode aub file contents.\n\n"
@@ -1025,7 +1031,7 @@ print_help(FILE *file)
"if omitted), 'always', or 'never'\n"
"  --no-pager  don't launch pager\n"
"  --no-offsetsdon't print instruction offsets\n",
-   basename(program_invocation_name));
+   basename(progname));
 }
 
 static bool
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] aubinator: stop using non portable error() function

[Jonathan Gray]

error() is a gnu extension and is not present on OpenBSD
and likely other systems.

Convert use of error to fprintf/strerror/exit.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/intel/tools/aubinator.c | 46 +
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 811f707..66107711 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -794,8 +793,10 @@ handle_trace_block(struct gen_spec *spec, uint32_t *p)
case AUB_TRACE_OP_DATA_WRITE:
   if (address_space != AUB_TRACE_MEMTYPE_GTT)
  break;
-  if (gtt_size < offset + size)
- error(EXIT_FAILURE, errno, "overflow gtt space");
+  if (gtt_size < offset + size) {
+ fprintf(stderr, "overflow gtt space: %s", strerror(errno));
+ exit(EXIT_FAILURE);
+  }
   memcpy((char *) gtt + offset, data, size);
   if (gtt_end < offset + size)
  gtt_end = offset + size;
@@ -834,16 +835,22 @@ aub_file_open(const char *filename)
file = malloc(sizeof *file);
file->filename = strdup(filename);
file->fd = open(file->filename, O_RDONLY);
-   if (file->fd == -1)
-  error(EXIT_FAILURE, errno, "open %s failed", file->filename);
+   if (file->fd == -1) {
+  fprintf(stderr, "open %s failed: %s", file->filename, strerror(errno));
+  exit(EXIT_FAILURE);
+   }
 
-   if (fstat(file->fd, >sb) == -1)
-  error(EXIT_FAILURE, errno, "stat failed");
+   if (fstat(file->fd, >sb) == -1) {
+  fprintf(stderr, "stat failed: %s", strerror(errno));
+  exit(EXIT_FAILURE);
+   }
 
file->map = mmap(NULL, file->sb.st_size,
 PROT_READ, MAP_SHARED, file->fd, 0);
-   if (file->map == MAP_FAILED)
-  error(EXIT_FAILURE, errno, "mmap failed");
+   if (file->map == MAP_FAILED) {
+  fprintf(stderr, "mmap failed: %s", strerror(errno));
+  exit(EXIT_FAILURE);
+   }
 
file->cursor = file->map;
file->end = file->map + file->sb.st_size / 4;
@@ -852,8 +859,10 @@ aub_file_open(const char *filename)
gtt_size = 1ul << 40;
gtt = mmap(NULL, gtt_size, PROT_READ | PROT_WRITE,
   MAP_PRIVATE | MAP_ANONYMOUS |  MAP_NORESERVE, -1, 0);
-   if (gtt == MAP_FAILED)
-  error(EXIT_FAILURE, errno, "failed to alloc gtt space");
+   if (gtt == MAP_FAILED) {
+  fprintf(stderr, "failed to alloc gtt space: %s", strerror(errno));
+  exit(1);
+   }
 
return file;
 }
@@ -1056,8 +1065,10 @@ int main(int argc, char *argv[])
   } else if (strcmp(argv[i], "--no-offsets") == 0) {
  option_print_offsets = false;
   } else if (is_prefix(argv[i], "--gen", )) {
- if (value == NULL)
-error(EXIT_FAILURE, 0, "option '--gen' requires an argument\n");
+ if (value == NULL) {
+fprintf(stderr, "option '--gen' requires an argument\n");
+exit(EXIT_FAILURE);
+ }
  found_arg_gen = true;
  gen_major = 0;
  gen_minor = 0;
@@ -1071,8 +1082,10 @@ int main(int argc, char *argv[])
 option_color = COLOR_NEVER;
  else if (strcmp(value, "auto") == 0)
 option_color = COLOR_AUTO;
- else
-error(EXIT_FAILURE, 0, "invalid value for --color: %s", value);
+ else {
+fprintf(stderr, "invalid value for --color: %s", value);
+exit(EXIT_FAILURE);
+ }
   } else if (strcmp(argv[i], "--help") == 0) {
  print_help(stdout);
  exit(EXIT_SUCCESS);
@@ -1131,8 +1144,9 @@ int main(int argc, char *argv[])
   gen_major = 9;
   gen_minor = 0;
} else {
-  error(EXIT_FAILURE, 0, "can't parse gen: %s, expected ivb, byt, hsw, "
+  fprintf(stderr, "can't parse gen: %s, expected ivb, byt, hsw, "
  "bdw, chv, skl, kbl or bxt\n", gen_val);
+  exit(EXIT_FAILURE);
}
 
/* Do this before we redirect stdout to pager. */
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/13] i965: Add a dependency on libisl

[Jonathan Gray]

On Fri, Apr 22, 2016 at 11:19:04AM -0700, Chad Versace wrote:
> On 04/22/2016 10:50 AM, Jason Ekstrand wrote:
> > 
> > 
> > On Fri, Apr 22, 2016 at 10:15 AM, Jonathan Gray <j...@jsg.id.au
> > <mailto:j...@jsg.id.au>> wrote:
> > 
> > On Fri, Apr 22, 2016 at 05:31:29PM +0100, Emil Velikov wrote:
> >> On 22 April 2016 at 16:08, Jonathan Gray <j...@jsg.id.au
> >> <mailto:j...@jsg.id.au>> wrote:
> >>> It is worth noting that the isl code extensively requires
> >>> designated initialisers on anonymous structs.  It isn't clear to
> >>> me when gcc introduced support for this but it isn't in 4.2.
> >>> 
> >> I think it should work for GCC 4.2 with -fms-extensions. We used
> >> to set -std=gnu99 for pre 4.6 which effectively enables it the
> >> extension. Can you double-check ?
> > 
> > The part that sets gnu99 for < gcc 4.6 is still there, using
> > -fms-extensions does not help for these. 
> 
> 
> > At least for the errors you're seeing there, I see two options:  1)
> > Use the isl_extentNd constructor functions in isl.h.  2) Stop making
> > isl_extentNd have anonymous unions.  I'm not sure how much the
> > anonymous unions are really doing for us but I'd like chad to chip in
> > before we throw them out.
> 
> I like the anonymous unions because they make some equations more concise.
> But, they don't provide anymore than that. I'll accept patches to remove
> them, as other people have also commented on their awkwardness.

Mark Kettenis has modified the base compiler to accept designated
initialisers for anonymous types so there is now no need to patch them
out for OpenBSD.

http://marc.info/?l=openbsd-cvs=146244074408249=2

>  
> > Here's another question: I know BSD doesn't ship gcc newer than 4.2
> > for license issues, but do you have a recent version of clang
> > available?
> 
> GCC 4.2 was released in 2007, and BSD won't upgrade it due to GPLv3.
> I believe it's unreasonable to promise Mesa will indefinitely restrict
> all new code to the feature set provided by a 2007-era GCC. As the years
> roll by, such a promise would become untenable.
> 
> Please try clang.
> 
> >>> Would you accept patches to remove them?
> >> While I cannot comment if they're OK with the idea, there might be 
> >> some confusion on the topic. There is anonymous and named. I
> >> believe developers were against the latter. Examples form [1]
> >> 
> >> struct bar { int i; }; // (1) unnamed, but tagged, ie *not*
> >> anonymous struct { int j; }; // (2) unnamed, but anonymous 
> >> struct { int k; } baz; // (3) named, but not tagged
> >> 
> >> Fwiw it would be great to use the more portable solution. Would
> >> C11 buy us anything ?
> 
> I believe that C11 does fix the problem. It standardized anonymous unions and 
> structs.
> However, if we need to support GCC 4.2, then we can't use C11. In fact, GCC's 
> C11 support
> is still incomplete as 5.0. I've discovered serious bugs as recently as GCC 
> 4.9.
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev