On Tue, 12 Feb 2019, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce
> SYMBOL"):
> > On Thu, 7 Feb 2019, Ian Jackson wrote:
> > > FAOD, I think you should expect people to declare the linker symb
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce
SYMBOL"):
> On Thu, 7 Feb 2019, Ian Jackson wrote:
> > FAOD, I think you should expect people to declare the linker symbols
> > either as I suggested:
> >
> > exte
On Thu, 7 Feb 2019, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce
> SYMBOL"):
> > I am OK with this approach. Maybe not the best IMO, but good enough. It
> > should also satisfy the MISRAC guys, as they wrote "i
>>> On 07.02.19 at 12:48, wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce
> SYMBOL"):
>> I am OK with this approach. Maybe not the best IMO, but good enough. It
>> should also satisfy the MISRAC guys, as they wrote "ide
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce
SYMBOL"):
> I am OK with this approach. Maybe not the best IMO, but good enough. It
> should also satisfy the MISRAC guys, as they wrote "ideally cast to
> uintptr_t only once": here we
On Wed, 6 Feb 2019, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
> > On 06.02.19 at 17:37, wrote:
> > > Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce
> > > SYMBOL"):
> &g
Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
> On 06.02.19 at 17:37, wrote:
> > Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
> >> - it allows the end-of-whatever symbols to also be handed to
>>> On 06.02.19 at 17:37, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
>> - it marks problem sites clearly (one of Stefano's goals),
>> - it isolates future changes to how exactly the comparisons
>>
Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
> On 06.02.19 at 16:41, wrote:
> > (i) define indirection variables eg end_ in an assembly language file.
> > (ii) convert to uintptr_t before comparing
> >
> > (i) is IMO wholly s
>>> On 06.02.19 at 16:41, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
>> As per my earlier reply, I've yet to see proof of a "code-breaking
>> optimization" that actually matches our case(s).
>
> I have
Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
> As per my earlier reply, I've yet to see proof of a "code-breaking
> optimization" that actually matches our case(s).
I have personally experienced a program being miscompiled beca
>>> On 05.02.19 at 15:56, wrote:
> On Mon, Feb 4, 2019 at 9:37 AM Jan Beulich wrote:
>> >>> On 01.02.19 at 19:52, wrote:
>> What I'm not sure I see is what you mean to
>> express with all you wrote in terms of finding a way out of the
>> current situation (besides requesting a vote)
>
> If
On Mon, Feb 4, 2019 at 9:37 AM Jan Beulich wrote:
>
> >>> On 01.02.19 at 19:52, wrote:
>
> I'm not going to reply in detail to all of what you wrote about fanatics,
> but I would like to say that I think compiler people less of that than
> you appear to imply, at least the ones I know. In
>>> On 04.02.19 at 20:08, wrote:
> On Mon, 4 Feb 2019, Jan Beulich wrote:
>> And btw - I can't judge on b. anyway, as I still don't know what
>> exactly MISRA compliance is to mean, with the rules to adhere to
>> suitably justified.
>
> I can't pretend to know exactly what MISRAC compliance
On 04/02/2019 20:08, Stefano Stabellini wrote:
> On Mon, 4 Feb 2019, Jan Beulich wrote:
> On 01.02.19 at 19:52, wrote:
>>
>> I'm not going to reply in detail to all of what you wrote about fanatics,
>> but I would like to say that I think compiler people less of that than
>> you appear to
On Mon, 4 Feb 2019, Jan Beulich wrote:
> >>> On 01.02.19 at 19:52, wrote:
>
> I'm not going to reply in detail to all of what you wrote about fanatics,
> but I would like to say that I think compiler people less of that than
> you appear to imply, at least the ones I know. In particular, they
>>> On 01.02.19 at 19:52, wrote:
I'm not going to reply in detail to all of what you wrote about fanatics,
but I would like to say that I think compiler people less of that than
you appear to imply, at least the ones I know. In particular, they can
be convinced of there being bugs by pointing
On Fri, 1 Feb 2019, George Dunlap wrote:
> On Tue, Jan 22, 2019 at 9:17 AM Jan Beulich wrote:
> >
> > >>> On 22.01.19 at 00:41, wrote:
> > > We haven't managed to reach consensus on this topic. Your view might be
> > > correct, but it is not necessarily supported by compilers' behavior,
> > >
On Tue, Jan 22, 2019 at 9:17 AM Jan Beulich wrote:
>
> >>> On 22.01.19 at 00:41, wrote:
> > We haven't managed to reach consensus on this topic. Your view might be
> > correct, but it is not necessarily supported by compilers' behavior,
> > which depends on the opinion of compilers engineers on
>>> On 22.01.19 at 00:41, wrote:
> We haven't managed to reach consensus on this topic. Your view might be
> correct, but it is not necessarily supported by compilers' behavior,
> which depends on the opinion of compilers engineers on the topic, and
> MISRAC compliance, which depends on the
>>> On 22.01.19 at 00:15, wrote:
> On Mon, 21 Jan 2019, Jan Beulich wrote:
>> >>> On 21.01.19 at 11:22, wrote:
>> > Hi Jan,
>> >
>> > On 21/01/2019 09:34, Jan Beulich wrote:
>> > On 18.01.19 at 11:48, wrote:
>> >>> On 18/01/2019 09:54, Jan Beulich wrote:
>> >>> On 18.01.19 at 02:24,
On 22/01/2019 00:41, Stefano Stabellini wrote:
> On Mon, 21 Jan 2019, Jan Beulich wrote:
> On 19.01.19 at 00:05, wrote:
>>> On Fri, 18 Jan 2019, Jan Beulich wrote:
>>> On 18.01.19 at 02:24, wrote:
> On Thu, 17 Jan 2019, Jan Beulich wrote:
> On 17.01.19 at 01:37, wrote:
On Mon, 21 Jan 2019, Jan Beulich wrote:
> >>> On 19.01.19 at 00:05, wrote:
> > On Fri, 18 Jan 2019, Jan Beulich wrote:
> >> >>> On 18.01.19 at 02:24, wrote:
> >> > On Thu, 17 Jan 2019, Jan Beulich wrote:
> >> >> >>> On 17.01.19 at 01:37, wrote:
> >> >> > On Wed, 16 Jan 2019, Jan Beulich wrote:
On Mon, 21 Jan 2019, Jan Beulich wrote:
> >>> On 21.01.19 at 11:22, wrote:
> > Hi Jan,
> >
> > On 21/01/2019 09:34, Jan Beulich wrote:
> > On 18.01.19 at 11:48, wrote:
> >>> On 18/01/2019 09:54, Jan Beulich wrote:
> >>> On 18.01.19 at 02:24, wrote:
> > On Thu, 17 Jan 2019, Jan
>>> On 21.01.19 at 11:22, wrote:
> Hi Jan,
>
> On 21/01/2019 09:34, Jan Beulich wrote:
> On 18.01.19 at 11:48, wrote:
>>> On 18/01/2019 09:54, Jan Beulich wrote:
>>> On 18.01.19 at 02:24, wrote:
> On Thu, 17 Jan 2019, Jan Beulich wrote:
> On 17.01.19 at 01:37, wrote:
Hi Jan,
On 21/01/2019 09:34, Jan Beulich wrote:
On 18.01.19 at 11:48, wrote:
On 18/01/2019 09:54, Jan Beulich wrote:
On 18.01.19 at 02:24, wrote:
On Thu, 17 Jan 2019, Jan Beulich wrote:
On 17.01.19 at 01:37, wrote:
On Wed, 16 Jan 2019, Jan Beulich wrote:
Stop. No. We very much can
>>> On 21.01.19 at 06:24, wrote:
> On Friday, January 18, 2019 6:05 PM, Stefano Stabellini wrote:
>> I don't think this is the case for MISRAC. C rules apply to C. Other
>> rules apply to assembly and linker scripts. This is something that
>> should be easy to check, and I hope that Stewart
>>> On 19.01.19 at 00:05, wrote:
> On Fri, 18 Jan 2019, Jan Beulich wrote:
>> >>> On 18.01.19 at 02:24, wrote:
>> > On Thu, 17 Jan 2019, Jan Beulich wrote:
>> >> >>> On 17.01.19 at 01:37, wrote:
>> >> > On Wed, 16 Jan 2019, Jan Beulich wrote:
>> >> >> In any event - since intermediate variables
>>> On 18.01.19 at 16:22, wrote:
> On 18/01/2019 11:09, Jan Beulich wrote:
> On 18.01.19 at 11:48, wrote:
>>> On 18/01/2019 09:54, Jan Beulich wrote:
>>> On 18.01.19 at 02:24, wrote:
> On Thu, 17 Jan 2019, Jan Beulich wrote:
> On 17.01.19 at 01:37, wrote:
>>> On Wed, 16
>>> On 18.01.19 at 11:48, wrote:
> On 18/01/2019 09:54, Jan Beulich wrote:
> On 18.01.19 at 02:24, wrote:
>>> On Thu, 17 Jan 2019, Jan Beulich wrote:
>>> On 17.01.19 at 01:37, wrote:
> On Wed, 16 Jan 2019, Jan Beulich wrote:
>> Stop. No. We very much can prove they are - _end points
On Friday, January 18, 2019 6:05 PM, Stefano Stabellini wrote:
> On Fri, 18 Jan 2019, Jan Beulich wrote:
> > >>> On 18.01.19 at 02:24, wrote:
> > > On Thu, 17 Jan 2019, Jan Beulich wrote:
> > >> >>> On 17.01.19 at 01:37, wrote:
> > >> > On Wed, 16 Jan 2019, Jan Beulich wrote:
> > >> >> In any
On Fri, 18 Jan 2019, Jan Beulich wrote:
> >>> On 18.01.19 at 02:24, wrote:
> > On Thu, 17 Jan 2019, Jan Beulich wrote:
> >> >>> On 17.01.19 at 01:37, wrote:
> >> > On Wed, 16 Jan 2019, Jan Beulich wrote:
> >> >> In any event - since intermediate variables merely hide the
> >> >> casting from the
Hi Jan,
On 18/01/2019 11:09, Jan Beulich wrote:
On 18.01.19 at 11:48, wrote:
On 18/01/2019 09:54, Jan Beulich wrote:
On 18.01.19 at 02:24, wrote:
On Thu, 17 Jan 2019, Jan Beulich wrote:
On 17.01.19 at 01:37, wrote:
On Wed, 16 Jan 2019, Jan Beulich wrote:
Stop. No. We very much can
>>> On 18.01.19 at 11:48, wrote:
> On 18/01/2019 09:54, Jan Beulich wrote:
> On 18.01.19 at 02:24, wrote:
>>> On Thu, 17 Jan 2019, Jan Beulich wrote:
>>> On 17.01.19 at 01:37, wrote:
> On Wed, 16 Jan 2019, Jan Beulich wrote:
>> Stop. No. We very much can prove they are - _end points
Hi Jan,
On 18/01/2019 09:54, Jan Beulich wrote:
On 18.01.19 at 02:24, wrote:
On Thu, 17 Jan 2019, Jan Beulich wrote:
On 17.01.19 at 01:37, wrote:
On Wed, 16 Jan 2019, Jan Beulich wrote:
Stop. No. We very much can prove they are - _end points at
one past the last element of _start[]. It is
>>> On 18.01.19 at 02:24, wrote:
> On Thu, 17 Jan 2019, Jan Beulich wrote:
>> >>> On 17.01.19 at 01:37, wrote:
>> > On Wed, 16 Jan 2019, Jan Beulich wrote:
>> >> In any event - since intermediate variables merely hide the
>> >> casting from the compiler, but they don't remove the casts, the
>>
On Thu, 17 Jan 2019, Jan Beulich wrote:
> >>> On 17.01.19 at 01:37, wrote:
> > On Wed, 16 Jan 2019, Jan Beulich wrote:
> >> In any event - since intermediate variables merely hide the
> >> casting from the compiler, but they don't remove the casts, the
> >> solution involving casts is better imo,
>>> On 17.01.19 at 01:37, wrote:
> On Wed, 16 Jan 2019, Jan Beulich wrote:
>> In any event - since intermediate variables merely hide the
>> casting from the compiler, but they don't remove the casts, the
>> solution involving casts is better imo, for incurring less overhead.
>
> This is where I
>>> On 17.01.19 at 01:41, wrote:
> I am happy to make this change and also work on your suggestion above
> about using .startof. / .sizeof. in var.S, if we agree on this approach.
But sadly we look to be quite far from agreeing on anything yet.
Jan
On Wed, 16 Jan 2019, Jan Beulich wrote:
> >>> On 16.01.19 at 00:36, wrote:
> > On Tue, 15 Jan 2019, Jan Beulich wrote:
> >> First of all we should explore whether the variables could also be
> >> linker generated, in particular to avoid the current symbols to be
> >> global (thus making it
On Wed, 16 Jan 2019, Jan Beulich wrote:
> >>> On 15.01.19 at 21:03, wrote:
> > On Tuesday, January 15, 2019 3:21 AM, Jan Beulich wrote:
> >> The thing that I don't understand though is how the undefined
> >> behavior (if there really is any) goes away: Even if you compare
> >> the contents of the
>>> On 16.01.19 at 00:36, wrote:
> On Tue, 15 Jan 2019, Jan Beulich wrote:
>> First of all we should explore whether the variables could also be
>> linker generated, in particular to avoid the current symbols to be
>> global (thus making it impossible to access them from C files in the
>> first
>>> On 15.01.19 at 21:03, wrote:
> On Tuesday, January 15, 2019 3:21 AM, Jan Beulich wrote:
>> The thing that I don't understand though is how the undefined
>> behavior (if there really is any) goes away: Even if you compare
>> the contents of the variables instead of the original (perhaps
>>
On 16/01/2019 00:36, Stefano Stabellini wrote:
> On Tue, 15 Jan 2019, Jan Beulich wrote:
>>> Yes, this instance is only the tip of the
>>> iceberg, we have a long road ahead, but we shouldn't really give up
>>> because it is going to be difficult :-) Stewart's approach would
>>> actually be
On 15/01/2019 21:03, Stewart Hildebrand wrote:
> On Tuesday, January 15, 2019 3:21 AM, Jan Beulich wrote:
>> First of all we should explore whether the variables could also be
>> linker generated, in particular to avoid the current symbols to be
>> global (thus making it impossible to access them
On Tue, 15 Jan 2019, Jan Beulich wrote:
> > Yes, this instance is only the tip of the
> > iceberg, we have a long road ahead, but we shouldn't really give up
> > because it is going to be difficult :-) Stewart's approach would
> > actually be compliant and help toward reducing reliance on
On Tuesday, January 15, 2019 3:21 AM, Jan Beulich wrote:
> >>> On 14.01.19 at 22:18, wrote:
> > Hi Jan,
> >
> > One question below to make a decision on the way forward.
> >
> > On Mon, 14 Jan 2019, Jan Beulich wrote:
> >> >>> On 14.01.19 at 04:45, wrote:
> >> > The difference would be whether
>>> On 15.01.19 at 13:23, wrote:
> Hi,
>
> On 1/15/19 12:04 PM, Jan Beulich wrote:
> On 15.01.19 at 12:51, wrote:
>>> Hi Jan,
>>>
>>> On 1/15/19 8:21 AM, Jan Beulich wrote:
>>> On 14.01.19 at 22:18, wrote:
> Hi Jan,
>
> One question below to make a decision on the way
Hi,
On 1/15/19 11:46 AM, Julien Grall wrote:
Hi Stefano,
On 1/11/19 9:37 PM, Stefano Stabellini wrote:
On Fri, 11 Jan 2019, Stewart Hildebrand wrote:
On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
Why don't we change the type
Hi,
On 1/15/19 12:04 PM, Jan Beulich wrote:
On 15.01.19 at 12:51, wrote:
Hi Jan,
On 1/15/19 8:21 AM, Jan Beulich wrote:
On 14.01.19 at 22:18, wrote:
Hi Jan,
One question below to make a decision on the way forward.
On Mon, 14 Jan 2019, Jan Beulich wrote:
On 14.01.19 at 04:45, wrote:
>>> On 15.01.19 at 12:51, wrote:
> Hi Jan,
>
> On 1/15/19 8:21 AM, Jan Beulich wrote:
> On 14.01.19 at 22:18, wrote:
>>> Hi Jan,
>>>
>>> One question below to make a decision on the way forward.
>>>
>>> On Mon, 14 Jan 2019, Jan Beulich wrote:
>>> On 14.01.19 at 04:45, wrote:
> So
Hi Jan,
On 1/15/19 8:21 AM, Jan Beulich wrote:
On 14.01.19 at 22:18, wrote:
Hi Jan,
One question below to make a decision on the way forward.
On Mon, 14 Jan 2019, Jan Beulich wrote:
On 14.01.19 at 04:45, wrote:
So let's keep the linker-accessible variable as a type that works for the
Hi Stefano,
On 1/11/19 9:37 PM, Stefano Stabellini wrote:
On Fri, 11 Jan 2019, Stewart Hildebrand wrote:
On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
Why don't we change the type of _start so it's not a pointer type?
Can you
>>> On 14.01.19 at 22:18, wrote:
> Hi Jan,
>
> One question below to make a decision on the way forward.
>
> On Mon, 14 Jan 2019, Jan Beulich wrote:
>> >>> On 14.01.19 at 04:45, wrote:
>> > So let's keep the linker-accessible variable as a type that works for the
>> > linker (which really
>>> On 14.01.19 at 18:24, wrote:
> On 14/01/2019 16:44, Jan Beulich wrote:
>>
>> extern struct my_struct __start[];
>> extern struct my_struct __end[];
>>
>> void test(const struct my_struct *);
>>
>> void foo(int i) {
>> test(i ? __start : __end);
>> }
>
> Your example doesn't contain
Hi Jan,
One question below to make a decision on the way forward.
On Mon, 14 Jan 2019, Jan Beulich wrote:
> >>> On 14.01.19 at 04:45, wrote:
> > So let's keep the linker-accessible variable as a type that works for the
> > linker (which really could be anything as long as you use the address,
Hi Jan,
On 14/01/2019 16:44, Jan Beulich wrote:
extern struct my_struct __start[];
extern struct my_struct __end[];
void test(const struct my_struct *);
void foo(int i) {
test(i ? __start : __end);
}
Your example doesn't contain any potential undefined behavior. So, how this
>>> On 14.01.19 at 17:28, wrote:
> Hi Jan,
>
> On 14/01/2019 15:52, Jan Beulich wrote:
> On 14.01.19 at 16:41, wrote:
>>> Hi Jan,
>>>
>>> On 14/01/2019 10:11, Jan Beulich wrote:
>>> On 11.01.19 at 19:04, wrote:
> On Fri, 11 Jan 2019, Jan Beulich wrote:
> On 11.01.19 at
>>> On 14.01.19 at 17:26, wrote:
> On Monday, January 14, 2019 10:53 AM, Jan Beulich wrote:
>> > Hi Jan,
>> >
>> > On 14/01/2019 10:11, Jan Beulich wrote:
>> > On 11.01.19 at 19:04, wrote:
>> >>> On Fri, 11 Jan 2019, Jan Beulich wrote:
>> >>> On 11.01.19 at 03:14, wrote:
>> > Hi
Hi Jan,
On 14/01/2019 15:52, Jan Beulich wrote:
On 14.01.19 at 16:41, wrote:
Hi Jan,
On 14/01/2019 10:11, Jan Beulich wrote:
On 11.01.19 at 19:04, wrote:
On Fri, 11 Jan 2019, Jan Beulich wrote:
On 11.01.19 at 03:14, wrote:
Hi Juergen, Jan,
I spoke with Julien: we are both convinced
On Monday, January 14, 2019 10:53 AM, Jan Beulich wrote:
> > Hi Jan,
> >
> > On 14/01/2019 10:11, Jan Beulich wrote:
> > On 11.01.19 at 19:04, wrote:
> >>> On Fri, 11 Jan 2019, Jan Beulich wrote:
> >>> On 11.01.19 at 03:14, wrote:
> > Hi Juergen, Jan,
> >
> > I spoke with
>>> On 14.01.19 at 16:41, wrote:
> Hi Jan,
>
> On 14/01/2019 10:11, Jan Beulich wrote:
> On 11.01.19 at 19:04, wrote:
>>> On Fri, 11 Jan 2019, Jan Beulich wrote:
>>> On 11.01.19 at 03:14, wrote:
> Hi Juergen, Jan,
>
> I spoke with Julien: we are both convinced that the
Hi Jan,
On 14/01/2019 10:11, Jan Beulich wrote:
On 11.01.19 at 19:04, wrote:
On Fri, 11 Jan 2019, Jan Beulich wrote:
On 11.01.19 at 03:14, wrote:
Hi Juergen, Jan,
I spoke with Julien: we are both convinced that the unsigned long
solution is best. But Julien also did some research and he
>>> On 14.01.19 at 04:45, wrote:
> So let's keep the linker-accessible variable as a type that works for the
> linker (which really could be anything as long as you use the address, not
> the value), but name it something else - a name that screams "DON'T USE ME
> UNLESS YOU KNOW WHAT YOU'RE
>>> On 11.01.19 at 19:04, wrote:
> On Fri, 11 Jan 2019, Jan Beulich wrote:
>> >>> On 11.01.19 at 03:14, wrote:
>> > Hi Juergen, Jan,
>> >
>> > I spoke with Julien: we are both convinced that the unsigned long
>> > solution is best. But Julien also did some research and he thinks that
>> > Jan's
On Friday, January 11, 2019 4:38 PM, Stefano Stabellini wrote:
> On Fri, 11 Jan 2019, Stewart Hildebrand wrote:
> > On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
> > > On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
> > > >
> > > > Why don't we change the type of _start so it's not
On Fri, 11 Jan 2019, Stewart Hildebrand wrote:
> On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
> > On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
> > >
> > > Why don't we change the type of _start so it's not a pointer type?
> >
> > Can you suggest a type that would be suitable?
>
On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
> On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
> >
> > Why don't we change the type of _start so it's not a pointer type?
>
> Can you suggest a type that would be suitable?
>
> Cheers,
Yes. My opinion is that the "sufficient-width
On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand, <
stewart.hildebr...@dornerworks.com> wrote:
>
> Why don't we change the type of _start so it's not a pointer type?
Can you suggest a type that would be suitable?
Cheers,
___
Xen-devel mailing list
On Friday, January 11, 2019 1:04 PM, Stefano Stabellini wrote:
> On Fri, 11 Jan 2019, Jan Beulich wrote:
> > >>> On 11.01.19 at 03:14, wrote:
> > > Hi Juergen, Jan,
> > >
> > > I spoke with Julien: we are both convinced that the unsigned long
> > > solution is best. But Julien also did some
On Fri, 11 Jan 2019, Jan Beulich wrote:
> >>> On 11.01.19 at 03:14, wrote:
> > Hi Juergen, Jan,
> >
> > I spoke with Julien: we are both convinced that the unsigned long
> > solution is best. But Julien also did some research and he thinks that
> > Jan's version (returning pointer type) not only
On Fri, 11 Jan 2019, Jan Beulich wrote:
> > If all we really care about is making PRQA happy, I believe it does support
> > some sort of comment-based suppression. I've seen comments like
> > /* PRQA S 0487 */ or /* PRQA S 0488 */ in various codebases, I'm guessing
> > comments like this have
On Fri, 11 Jan 2019, Juergen Gross wrote:
> On 11/01/2019 03:14, Stefano Stabellini wrote:
> > Hi Juergen, Jan,
> >
> > I spoke with Julien: we are both convinced that the unsigned long
> > solution is best. But Julien also did some research and he thinks that
> > Jan's version (returning pointer
>>> On 11.01.19 at 03:14, wrote:
> Hi Juergen, Jan,
>
> I spoke with Julien: we are both convinced that the unsigned long
> solution is best. But Julien also did some research and he thinks that
> Jan's version (returning pointer type) not only does not help with
> MISRA-C, but also doesn't
>>> On 10.01.19 at 19:46, wrote:
> On Thursday, January 10, 2019 12:30 PM, Stefano Stabellini wrote:
>> On Thu, 10 Jan 2019, Jan Beulich wrote:
>> > >>> On 10.01.19 at 03:40, wrote:
>> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
>> > > wrote:
>> > >
>> > >> Introduce a macro, SYMBOL,
On 11/01/2019 03:14, Stefano Stabellini wrote:
> Hi Juergen, Jan,
>
> I spoke with Julien: we are both convinced that the unsigned long
> solution is best. But Julien also did some research and he thinks that
> Jan's version (returning pointer type) not only does not help with
> MISRA-C, but also
Hi Juergen, Jan,
I spoke with Julien: we are both convinced that the unsigned long
solution is best. But Julien also did some research and he thinks that
Jan's version (returning pointer type) not only does not help with
MISRA-C, but also doesn't solve the potential GCC problem either. A
On Thu, 10 Jan 2019, 15:36 Stefano Stabellini,
wrote:
> On Thu, 10 Jan 2019, Julien Grall wrote:
> > On Thu, 10 Jan 2019, 12:29 Stefano Stabellini,
> wrote:
> > On Thu, 10 Jan 2019, Jan Beulich wrote:
> > > >>> On 10.01.19 at 03:40, wrote:
> > > > On Wed, 9 Jan 2019, 18:43
On Thu, 10 Jan 2019, Julien Grall wrote:
> On Thu, 10 Jan 2019, 12:29 Stefano Stabellini, wrote:
> On Thu, 10 Jan 2019, Jan Beulich wrote:
> > >>> On 10.01.19 at 03:40, wrote:
> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
>
> > > wrote:
> > >
> > >>
On Thu, 10 Jan 2019, 12:29 Stefano Stabellini,
wrote:
> On Thu, 10 Jan 2019, Jan Beulich wrote:
> > >>> On 10.01.19 at 03:40, wrote:
> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> > > wrote:
> > >
> > >> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> > >> meant
On Thu, 10 Jan 2019, Stewart Hildebrand wrote:
> On Thursday, January 10, 2019 12:30 PM, Stefano Stabellini wrote:
> > On Thu, 10 Jan 2019, Jan Beulich wrote:
> > > >>> On 10.01.19 at 03:40, wrote:
> > > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> > > > wrote:
> > > >
> > > >> Introduce a
On Thursday, January 10, 2019 12:30 PM, Stefano Stabellini wrote:
> On Thu, 10 Jan 2019, Jan Beulich wrote:
> > >>> On 10.01.19 at 03:40, wrote:
> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> > > wrote:
> > >
> > >> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> >
On Thu, 10 Jan 2019, Jan Beulich wrote:
> >>> On 10.01.19 at 00:42, wrote:
> > --- a/xen/include/xen/compiler.h
> > +++ b/xen/include/xen/compiler.h
> > @@ -99,6 +99,16 @@
> > __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
> > (typeof(ptr)) (__ptr + (off)); })
> >
> > +/*
> > + *
On Thu, 10 Jan 2019, Jan Beulich wrote:
> >>> On 10.01.19 at 03:40, wrote:
> > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> > wrote:
> >
> >> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> >> meant to be used everywhere symbols such as _stext and _etext are used
> >>
On Wed, 9 Jan 2019, Julien Grall wrote:
> Hi,
> Sorry for the formatting.
>
> On Wed, 9 Jan 2019, 18:43 Stefano Stabellini, wrote:
> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> meant to be used everywhere symbols such as _stext and _etext are used
>
>>> On 10.01.19 at 00:42, wrote:
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -99,6 +99,16 @@
> __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
> (typeof(ptr)) (__ptr + (off)); })
>
> +/*
> + * Similar to RELOC_HIDE, but written to be used with symbols such
>>> On 10.01.19 at 03:40, wrote:
> On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> wrote:
>
>> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
>> meant to be used everywhere symbols such as _stext and _etext are used
>> in the code. It can take an array type as a parameter,
Hi,
Sorry for the formatting.
On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
wrote:
> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> meant to be used everywhere symbols such as _stext and _etext are used
> in the code. It can take an array type as a parameter, and it
Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
meant to be used everywhere symbols such as _stext and _etext are used
in the code. It can take an array type as a parameter, and it returns
the same type.
SYMBOL is needed when accessing symbols such as _stext and _etext
89 matches
Mail list logo
