Good point. Yes, the circular dependencies are problematic and there's
also the question of casting to different object types which might have
differing alignments. The simplest solution is the (void *) intermediate
cast in those specific cases.
So please ignore this patch. I'll post the other one for odp-dpdk. The
issue in the DPDK code itself is one we can't fix ourselves so I'd ignore
it for now.
On Thu, Jul 9, 2015 at 5:09 AM, Zoltan Kiss <zoltan.k...@linaro.org> wrote:
> I'm not sure it's sufficient enough. What happens if you cast the type
> into something which is not 8 byte aligned, but bigger? The example Mike
> saw was in ODP-DPDK CI:
>
> 18:50:48 ./include/odp_pool_internal.h:92:9: error: cast from
> 'odp_buffer_t' (aka 'struct (anonymous at
> ./include/odp/plat/buffer_types.h:29:9) *') to 'odp_buffer_hdr_t *' (aka
> 'struct odp_buffer_hdr_t *') increases required alignment from 1 to 64
> [-Werror,-Wcast-align]
> 18:50:48 return (odp_buffer_hdr_t *)buf;
>
> It wouldn't pass with this either, because odp_buffer_hdr_t is 64 byte
> aligned. You can't really find an universal size, because that could force
> unnecessary alignment restrictions to other types using this macro.
> I would still recommend what I wrote in a separate mail chain:
>
> typedef ODP_HANDLE_T(odp_buffer_t, sizeof(odp_buffer_hdr_t));
> ...
> #define odp_handle_t(align) struct { uint8_t unused_dummy_var[align]; } *
> /** C/C++ helper macro for strong typing */
> #define ODP_HANDLE_T(type, align) odp_handle_t(align) type
>
> That would make this flexible: you can use just 1 if your opaque type is
> never casted to a pointer for a different type, or
> sizeof(that_different_type) if it is.
> The only problem I see in case of the above example, that you don't see
> the odp_buffer_hdr_t definition in buffer_types.h
>
> Zoli
>
>
>
>
> On 08/07/15 21:41, Bill Fischofer wrote:
>
>> ODP handles are abstract types however because compilers see their
>> implementation they assume these have alignments that can result in false
>> lint warnings. Increasing the apparent alignment to uint64_t removes
>> these.
>> It has no effect on ODP operation or performance.
>>
>> Signed-off-by: Bill Fischofer <bill.fischo...@linaro.org>
>> ---
>> platform/linux-generic/include/odp/plat/strong_types.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/odp/plat/strong_types.h
>> b/platform/linux-generic/include/odp/plat/strong_types.h
>> index a53d763..3eb4556 100644
>> --- a/platform/linux-generic/include/odp/plat/strong_types.h
>> +++ b/platform/linux-generic/include/odp/plat/strong_types.h
>> @@ -17,9 +17,9 @@
>>
>> /** Use strong typing for ODP types */
>> #ifdef __cplusplus
>> -#define ODP_HANDLE_T(type) struct _##type { uint8_t unused_dummy_var; }
>> *type
>> +#define ODP_HANDLE_T(type) struct _##type { uint64_t unused_dummy_var; }
>> *type
>> #else
>> -#define odp_handle_t struct { uint8_t unused_dummy_var; } *
>> +#define odp_handle_t struct { uint64_t unused_dummy_var; } *
>> /** C/C++ helper macro for strong typing */
>> #define ODP_HANDLE_T(type) odp_handle_t type
>> #endif
>>
>>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
