Displaying 6 results from an estimated 6 matches for "some_label".
2015 Aug 26
2
Proposal: arbitrary relocations in constant global initializers
...rs in the
object file, and we can solve the documentation problem with reference to
the object file format documentation, but it would require our documentation
to depend on sometimes poorly documented object file formats.
Option 2 could look something like this (produces the same bytes as "b
some_label" in every object format when targeting ARM, or "b.w some_label"
when targeting Thumb):
i32 arm_b (void ()* @some_label)
and that would be easy to document on its own. The downside is that it's
pretty specific to my use case, but maybe that's ok.
2 seems like it would be le...
2016 Oct 07
2
Proposal: arbitrary relocations in constant global initializers
...ion problem with reference to
> > the object file format documentation, but it would require our
> documentation
> > to depend on sometimes poorly documented object file formats.
> >
> > Option 2 could look something like this (produces the same bytes as "b
> > some_label" in every object format when targeting ARM, or "b.w
> some_label"
> > when targeting Thumb):
> >
> > i32 arm_b (void ()* @some_label)
> >
> > and that would be easy to document on its own. The downside is that it's
> > pretty specific to my...
2016 Oct 07
2
Proposal: arbitrary relocations in constant global initializers
...file format documentation, but it would require our
> >> > documentation
> >> > to depend on sometimes poorly documented object file formats.
> >> >
> >> > Option 2 could look something like this (produces the same bytes as "b
> >> > some_label" in every object format when targeting ARM, or "b.w
> >> > some_label"
> >> > when targeting Thumb):
> >> >
> >> > i32 arm_b (void ()* @some_label)
> >> >
> >> > and that would be easy to document on its own. The...
2016 Oct 07
2
Proposal: arbitrary relocations in constant global initializers
...t; > documentation
> >> >> > to depend on sometimes poorly documented object file formats.
> >> >> >
> >> >> > Option 2 could look something like this (produces the same bytes as
> >> >> > "b
> >> >> > some_label" in every object format when targeting ARM, or "b.w
> >> >> > some_label"
> >> >> > when targeting Thumb):
> >> >> >
> >> >> > i32 arm_b (void ()* @some_label)
> >> >> >
> >> >> &...
2015 Aug 26
2
Proposal: arbitrary relocations in constant global initializers
On Wed, Aug 26, 2015 at 11:49:46AM -0400, Rafael Espíndola wrote:
> This is pr10368.
>
> Do we really need to support hard coded relocation numbers? Looks like
> the examples above have a representation as constant expressions:
>
> (sub (add (ptrtoint @foo) 0xeafffffe) cur_pos)
>
> no?
I'm not sure if this would be sufficient. The R_ARM_JUMP24 relocation
on ARM
2014 Mar 23
2
global append changes since version 5
...is is, of course, a simplified case just to show the problem.
There is one case in which the "global append" is *not* ignored in
versions 5-6.02:
***
# The following is a global directive
APPEND root=/dev/sda2
DEFAULT mykernel
# The following entry includes an append line
LABEL some_label
KERNEL mykernel
APPEND some_additional_options
# The following entry does not include an append line
LABEL mylabel
KERNEL mykernel
***
In the above example, the "global append" is ignored by the 'default'
command and by 'label' entries that already have an 'a...