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
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
>>> 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,
>>> 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 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 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 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 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, 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 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, 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, 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
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 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
>>> 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.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 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 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, 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 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, 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 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, 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 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 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 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
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 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
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
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 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
>>> 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
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
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
>>> 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
>>> 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
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
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
>>> 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,
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
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
>>> 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
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 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 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 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.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.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 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 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 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 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 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 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
>> >>
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 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 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 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
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 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 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 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 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
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 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:
>>
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 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 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 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.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 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 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 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 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 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 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 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 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'
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 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"):
> 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 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 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 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
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 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
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
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 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
89 matches
Mail list logo
