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 wouldn&#
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
>> are
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
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 becaus
>>> 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 you'
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 particu
>>> 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 means
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 impl
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 can
>>> 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 out
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,
> > > whi
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 t
>>> 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 opinio
>>> 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, wr
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 Beuli
>>> 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 prove
>>> 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 should
>>> 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 eve
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 prove
>>> 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 impossi
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 pl
>>> 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
>> cast
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 complia
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 f
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 undefined
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 we
>>> 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 forwar
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 o
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:
S
>>> 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 le
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
link
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 could
>>> 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 an
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, no
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
releva
>>> 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 03:14
>>> 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 Juer
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 tha
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 Juli
>>> 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 unsig
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 th
>>> 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 DOING
>>> 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 in
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
Xen-de
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 resea
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 somet
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 solve
>>> 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, which
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
descripti
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 Ste
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:
> > >
> > >> Int
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 to
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 m
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)); })
> >
> > +/*
> > + * Simila
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
> >> i
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
> in
>>> 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 retu
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
because
89 matches
Mail list logo
