On Tue, Mar 24, 2020 at 11:32:32AM +0100, Martin Liška wrote:
> >From 82b8731f304c734353c34ddaf1b1265341a90882 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Tue, 24 Mar 2020 09:12:50 +0100
> Subject: [PATCH] Improve endianess detection.
>
> include/ChangeLog:
>
> 2020-03-24 Martin Liska
On 3/24/20 10:18 AM, Jakub Jelinek wrote:
Hi!
So, assuming I'm on glibc with GCC 4.5 on powerpc64-linux.
On Tue, Mar 24, 2020 at 09:49:42AM +0100, Martin Liška wrote:
+/* Detect endianess based on __BYTE_ORDER__ macro. */
+#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
+
Hi!
So, assuming I'm on glibc with GCC 4.5 on powerpc64-linux.
On Tue, Mar 24, 2020 at 09:49:42AM +0100, Martin Liška wrote:
> +/* Detect endianess based on __BYTE_ORDER__ macro. */
> +#if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \
> +defined(__ORDER_LITTLE_ENDIAN__) && de
On 3/24/20 9:31 AM, Jakub Jelinek wrote:
On Tue, Mar 24, 2020 at 09:19:12AM +0100, Martin Liška wrote:
2020-03-24 Martin Liska
PR lto/94249
* plugin-api.h: Add more robust endianess detection.
---
include/plugin-api.h | 43 +--
1 fil
On Tue, Mar 24, 2020 at 09:19:12AM +0100, Martin Liška wrote:
> 2020-03-24 Martin Liska
>
> PR lto/94249
> * plugin-api.h: Add more robust endianess detection.
> ---
> include/plugin-api.h | 43 +--
> 1 file changed, 41 insertions(+), 2 delet
All right, there's update endianess detection that should be robust
enough.
I've tested that on x86_64-linux-gnu and sparc64-linux.
Ready for master?
Thanks,
Martin
>From be4ce2c54672e7772586c13d6e37c63124624bbc Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 24 Mar 2020 09:12:50 +0100
S
On Mon, Mar 23, 2020 at 10:17 AM Martin Liška wrote:
>
> On 3/23/20 5:06 PM, H.J. Lu wrote:
> > #if __has_include ()
> > ...
> > #ifdef __BYTE_ORDER
> > #if __BYTE_ORDER == __BIG_ENDIAN
> > ...
> >
> > We support V2 interface only if defines __BYTE_ORDER?
>
> Right now we rely on __BIG_ENDIAN__ w
On 3/23/20 5:06 PM, H.J. Lu wrote:
#if __has_include ()
...
#ifdef __BYTE_ORDER
#if __BYTE_ORDER == __BIG_ENDIAN
...
We support V2 interface only if defines __BYTE_ORDER?
Right now we rely on __BIG_ENDIAN__ which is a weak endianess detection.
So we either need a very robust endianess detecti
On Mon, Mar 23, 2020 at 8:39 AM Richard Biener
wrote:
>
> On Mon, Mar 23, 2020 at 4:07 PM Martin Liška wrote:
> >
> > Hi.
> >
> > There's a patch draft that will do the proper versioning of API.
>
> Would sth like this be preferred on the binutils side or would
> splitting up the 'def' field via
On Mon, Mar 23, 2020 at 4:07 PM Martin Liška wrote:
>
> Hi.
>
> There's a patch draft that will do the proper versioning of API.
Would sth like this be preferred on the binutils side or would
splitting up the 'def' field via shift&masking better?
@@ -87,25 +87,30 @@ struct ld_plugin_symbol
{
On March 23, 2020 1:43:30 PM GMT+01:00, "Martin Liška" wrote:
>On 3/23/20 11:35 AM, Jakub Jelinek wrote:
>> I don't think so. That is about the target, but you care about the
>host.
>
>I see.
>
>> Wouldn't it be much easier not to do this and simply use macros for
>bits
>> from the full 32-bit va
Hi.
There's a patch draft that will do the proper versioning of API.
It's a subject for discussion.
Martin
>From b3f88adc91c36649bec3ed125b3e36ee89143bab Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 23 Mar 2020 16:01:29 +0100
Subject: [PATCH] Introduce ld_plugin_symbol_v2 for LTO plug
On 3/23/20 11:35 AM, Jakub Jelinek wrote:
I don't think so. That is about the target, but you care about the host.
I see.
Wouldn't it be much easier not to do this and simply use macros for bits
from the full 32-bit value (and use shifts)?
That would make the current small hack even bigger
On Mon, Mar 23, 2020 at 11:28:00AM +0100, Martin Liška wrote:
> > > > You can use them but should be prepared for some fallback (e.g.
> > > > endian.h,
> > > > whatever else).
> > > > And there is also PDP endian...
> > >
> > > Huh, are we talking about something so complex like:
> > > https://gi
On 3/23/20 11:10 AM, Jakub Jelinek wrote:
On Mon, Mar 23, 2020 at 11:00:21AM +0100, Martin Liška wrote:
On 3/23/20 10:43 AM, Jakub Jelinek wrote:
On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote:
Hi.
As seen in the PR, sparc64 LTO test-suite fails due to missing
definition of __BI
On Mon, Mar 23, 2020 at 11:00:21AM +0100, Martin Liška wrote:
> On 3/23/20 10:43 AM, Jakub Jelinek wrote:
> > On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote:
> > > Hi.
> > >
> > > As seen in the PR, sparc64 LTO test-suite fails due to missing
> > > definition of __BIG_ENDIAN__ macro.
On 3/23/20 10:43 AM, Jakub Jelinek wrote:
On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote:
Hi.
As seen in the PR, sparc64 LTO test-suite fails due to missing
definition of __BIG_ENDIAN__ macro. That said, I updated the
endianess detection to use __BYTE_ORDER__.
I tested the detect
On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote:
> Hi.
>
> As seen in the PR, sparc64 LTO test-suite fails due to missing
> definition of __BIG_ENDIAN__ macro. That said, I updated the
> endianess detection to use __BYTE_ORDER__.
>
> I tested the detection on x86_64-linux-gnu, ppc64-
18 matches
Mail list logo
