Hello,
2018-01-18 22:48 GMT+01:00 Yunlian Jiang :
> My question is.
>the ash_ptr_to_globals_misc, ash_ptr_to_globals_memstack and
> ash_ptr_to_globals_var
> are defined in ash_ptr_hack.c as normal pointers. But in ash.c, they are
> declared as const
> pointers. What is the benefit of doing th
Hi,
> There also checks for GCC_COMBINE, but it does the opposite of your patch.
Sorry, my bad. It does the same! :/
Cheers,
Xabier Oneca_,,_
--
Que te lo pases bien,
xOneca_,,_
2018-01-18 23:02 GMT+01:00 Xabier Oneca -- xOneca :
> Hello,
>
> 2018-01-18 22:48 GMT+01:00 Yunlian Jiang :
>> My
On 18 Jan 2018 13:48, Yunlian Jiang wrote:
>I tried to build busybox with clang and use it to create recovery image
> for ChromeOS.
> It fails to recover an arm based ChromeBook.
is it that busybox is crashing ? is clang/lld placing this pointer in const
memory (even though we have section(".
Hi Mike,
>> My question is.
>>the ash_ptr_to_globals_misc, ash_ptr_to_globals_memstack
>> and ash_ptr_to_globals_var
>> are defined in ash_ptr_hack.c as normal pointers. But in ash.c, they are
>> declared as const
>> pointers. What is the benefit of doing that?
>
> the pointer itself is the t
On 20 Jan 2018 12:18, Xabier Oneca -- xOneca wrote:
> >> My question is.
> >>the ash_ptr_to_globals_misc, ash_ptr_to_globals_memstack
> >> and ash_ptr_to_globals_var
> >> are defined in ash_ptr_hack.c as normal pointers. But in ash.c, they are
> >> declared as const
> >> pointers. What is the
Mike Frysinger wrote:
the pointer itself is the thing that is const, not the memory it points to.
this lets the compiler optimize the loads by generating relocations via the
pointer ... there's the fixup at the initial load time, but after that, it's
just offsets to a constant memory location. b
On 20 Jan 2018 19:03, Ralf Friedl wrote:
> Mike Frysinger wrote:
> > the pointer itself is the thing that is const, not the memory it points to.
> > this lets the compiler optimize the loads by generating relocations via the
> > pointer ... there's the fixup at the initial load time, but after that
On 22 Jan 2018 09:23, Yunlian Jiang wrote:
> On Fri, Jan 19, 2018 at 3:32 PM, Mike Frysinger wrote:
> > On 18 Jan 2018 13:48, Yunlian Jiang wrote:
> > >I tried to build busybox with clang and use it to create recovery
> > image
> > > for ChromeOS.
> > > It fails to recover an arm based ChromeBo
Mike Frysinger schrieb:
On 22 Jan 2018 09:23, Yunlian Jiang wrote:
On Fri, Jan 19, 2018 at 3:32 PM, Mike Frysinger wrote:
is it that busybox is crashing ? is clang/lld placing this pointer in
const
memory (even though we have section(".data")) ? or is it generating an
abort
when it reaches wh
Mike Frysinger wrote:
On 20 Jan 2018 19:03, Ralf Friedl wrote:
Mike Frysinger wrote:
the pointer itself is the thing that is const, not the memory it points to.
this lets the compiler optimize the loads by generating relocations via the
pointer ... there's the fixup at the initial load time, bu
On 22 Jan 2018 22:54, Ralf Friedl wrote:
> Mike Frysinger schrieb:
> > On 22 Jan 2018 09:23, Yunlian Jiang wrote:
> >> On Fri, Jan 19, 2018 at 3:32 PM, Mike Frysinger wrote:
> >>> is it that busybox is crashing ? is clang/lld placing this pointer in
> >>> const
> >>> memory (even though we have se
Mike Frysinger schrieb:
On 22 Jan 2018 22:54, Ralf Friedl wrote:
Mike Frysinger schrieb:
On 22 Jan 2018 09:23, Yunlian Jiang wrote:
On Fri, Jan 19, 2018 at 3:32 PM, Mike Frysinger wrote:
is it that busybox is crashing ? is clang/lld placing this pointer in
const
memory (even though we have s
On 23 Jan 2018 07:11, Ralf Friedl wrote:
> Mike Frysinger schrieb:
> > On 22 Jan 2018 22:54, Ralf Friedl wrote:
> >> Mike Frysinger schrieb:
> >>> On 22 Jan 2018 09:23, Yunlian Jiang wrote:
> On Fri, Jan 19, 2018 at 3:32 PM, Mike Frysinger wrote:
> > is it that busybox is crashing ? is cl
On 22 Jan 2018 22:59, Ralf Friedl wrote:
> Mike Frysinger wrote:
> > On 20 Jan 2018 19:03, Ralf Friedl wrote:
> >> Mike Frysinger wrote:
> >>> the pointer itself is the thing that is const, not the memory it points
> >>> to.
> >>> this lets the compiler optimize the loads by generating relocations
On 26 Jan 2018 11:39, Yunlian Jiang wrote:
> I will use a similar issue in lineedit.c to explain the problem. (it is
> easier to reproduce).
> The problem is that
> clang thinks lineedit_ptr_to_statics is a constant pointer, so the pointer
> should be unchanged. As a result, inside a function, it
>
On Thu, Jan 18, 2018 at 10:48 PM, Yunlian Jiang wrote:
> Hi,
>I tried to build busybox with clang and use it to create recovery image
> for ChromeOS.
> It fails to recover an arm based ChromeBook.
>I digged a little bit.
>Below patch makes it work. My question is.
>the ash_ptr_to_
On 28 Jan 2018 20:41, Denys Vlasenko wrote:
> On Thu, Jan 18, 2018 at 10:48 PM, Yunlian Jiang wrote:
> > Hi,
> >I tried to build busybox with clang and use it to create recovery image
> > for ChromeOS.
> > It fails to recover an arm based ChromeBook.
> >I digged a little bit.
> >Below
On Fri, Jan 26, 2018 at 8:39 PM, Yunlian Jiang wrote:
> I will use a similar issue in lineedit.c to explain the problem. (it is
> easier to reproduce).
> The problem is that
> clang thinks lineedit_ptr_to_statics is a constant pointer, so the pointer
> should be unchanged. As a result, inside a fu
On 30 Jan 2018 04:10, Denys Vlasenko wrote:
> On Fri, Jan 26, 2018 at 8:39 PM, Yunlian Jiang wrote:
> > I will use a similar issue in lineedit.c to explain the problem. (it is
> > easier to reproduce).
> > The problem is that
> > clang thinks lineedit_ptr_to_statics is a constant pointer, so the p
19 matches
Mail list logo
