[7/7] eal: improve musl compatibility
Checks
Commit Message
Musl complains about pthread id being of wrong size. Fix it by
casting to 64-bit and printing 64-bit hex unconditionally.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
lib/librte_eal/linuxapp/eal/eal.c | 5 +++--
lib/librte_eal/linuxapp/eal/eal_thread.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
Comments
On Wed, Aug 29, 2018 at 12:56:21PM +0100, Anatoly Burakov wrote:
> Musl complains about pthread id being of wrong size. Fix it by
> casting to 64-bit and printing 64-bit hex unconditionally.
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
Given that on linux pthread_t is a pointer type, will this not give other
warnings of casting from pointer to integer of a different type when
compiling 32-bit? For safety I suggest casting to long or uintptr_t
instead, to ensure we always get an int of the right size.
/Bruce
On Wed, Aug 29, 2018 at 01:39:26PM +0100, Bruce Richardson wrote:
> On Wed, Aug 29, 2018 at 12:56:21PM +0100, Anatoly Burakov wrote:
> > Musl complains about pthread id being of wrong size. Fix it by
> > casting to 64-bit and printing 64-bit hex unconditionally.
> >
> > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---
> Given that on linux pthread_t is a pointer type, will this not give other
> warnings of casting from pointer to integer of a different type when
s/type/size/
> compiling 32-bit? For safety I suggest casting to long or uintptr_t
> instead, to ensure we always get an int of the right size.
>
> /Bruce
On 29-Aug-18 1:39 PM, Bruce Richardson wrote:
> On Wed, Aug 29, 2018 at 12:56:21PM +0100, Anatoly Burakov wrote:
>> Musl complains about pthread id being of wrong size. Fix it by
>> casting to 64-bit and printing 64-bit hex unconditionally.
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>> ---
> Given that on linux pthread_t is a pointer type, will this not give other
> warnings of casting from pointer to integer of a different type when
> compiling 32-bit? For safety I suggest casting to long or uintptr_t
> instead, to ensure we always get an int of the right size.
>
> /Bruce
>
Sure, will fix.
On Wed, 29 Aug 2018 12:56:21 +0100
Anatoly Burakov <anatoly.burakov@intel.com> wrote:
> Musl complains about pthread id being of wrong size. Fix it by
> casting to 64-bit and printing 64-bit hex unconditionally.
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
What is pthread_t on musl? On Linux it is unsigned long.
On Wed, 29 Aug 2018 15:09:47 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 29-Aug-18 1:39 PM, Bruce Richardson wrote:
> > On Wed, Aug 29, 2018 at 12:56:21PM +0100, Anatoly Burakov wrote:
> >> Musl complains about pthread id being of wrong size. Fix it by
> >> casting to 64-bit and printing 64-bit hex unconditionally.
> >>
> >> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> >> ---
> > Given that on linux pthread_t is a pointer type, will this not give other
> > warnings of casting from pointer to integer of a different type when
> > compiling 32-bit? For safety I suggest casting to long or uintptr_t
> > instead, to ensure we always get an int of the right size.
> >
> > /Bruce
> >
>
> Sure, will fix.
>
> --
> Thanks,
> Anatoly
Maybe use gettid() to get thread id which is actually way more useful
than the pointer value. Of course, glibc doesn't want to provide a syscall
wrapper for this.
On 29-Aug-18 5:47 PM, Stephen Hemminger wrote:
> On Wed, 29 Aug 2018 15:09:47 +0100
> "Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
>
>> On 29-Aug-18 1:39 PM, Bruce Richardson wrote:
>>> On Wed, Aug 29, 2018 at 12:56:21PM +0100, Anatoly Burakov wrote:
>>>> Musl complains about pthread id being of wrong size. Fix it by
>>>> casting to 64-bit and printing 64-bit hex unconditionally.
>>>>
>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>>>> ---
>>> Given that on linux pthread_t is a pointer type, will this not give other
>>> warnings of casting from pointer to integer of a different type when
>>> compiling 32-bit? For safety I suggest casting to long or uintptr_t
>>> instead, to ensure we always get an int of the right size.
>>>
>>> /Bruce
>>>
>>
>> Sure, will fix.
>>
>> --
>> Thanks,
>> Anatoly
>
> Maybe use gettid() to get thread id which is actually way more useful
> than the pointer value. Of course, glibc doesn't want to provide a syscall
> wrapper for this.
>
>
We have rte_gettid() call.
@@ -3,6 +3,7 @@
* Copyright(c) 2012-2014 6WIND S.A.
*/
+#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
@@ -979,8 +980,8 @@ rte_eal_init(int argc, char **argv)
ret = eal_thread_dump_affinity(cpuset, sizeof(cpuset));
- RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%x;cpuset=[%s%s])\n",
- rte_config.master_lcore, (int)thread_id, cpuset,
+ RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%" PRIx64" ;cpuset=[%s%s])\n",
+ rte_config.master_lcore, (uint64_t)thread_id, cpuset,
ret == 0 ? "" : "...");
RTE_LCORE_FOREACH_SLAVE(i) {
@@ -3,6 +3,7 @@
*/
#include <errno.h>
+#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
@@ -121,8 +122,8 @@ eal_thread_loop(__attribute__((unused)) void *arg)
ret = eal_thread_dump_affinity(cpuset, sizeof(cpuset));
- RTE_LOG(DEBUG, EAL, "lcore %u is ready (tid=%x;cpuset=[%s%s])\n",
- lcore_id, (int)thread_id, cpuset, ret == 0 ? "" : "...");
+ RTE_LOG(DEBUG, EAL, "lcore %u is ready (tid=%" PRIx64 ";cpuset=[%s%s])\n",
+ lcore_id, (uint64_t)thread_id, cpuset, ret == 0 ? "" : "...");
/* read on our pipe to get commands */
while (1) {