Displaying 10 results from an estimated 10 matches for "nonalloc".
Did you mean:
noalloc
2020 Jul 30
3
Switch to ld.bfd tombstone behavior by default
...ill go away. Moreover, the user has to look up the semantics of
'bfd'. And the 'bfd' semantics may get stale if GNU ld updates its behaviors.
We can also take it from another perspective, do the opt-in options look
intimidating just because they are too long?
-z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe'
-z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe'
-z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff'
We can support signed integers:
-z 'dead-reloc-in-nonalloc=.debug_ranges=-2'
-z 'dead-reloc-in-nonalloc=.debug_loc=-2...
2020 Aug 05
2
Switch to ld.bfd tombstone behavior by default
...emantics of
>> 'bfd'. And the 'bfd' semantics may get stale if GNU ld updates its behaviors.
>>
>> We can also take it from another perspective, do the opt-in options look
>> intimidating just because they are too long?
>>
>> -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe'
>> -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe'
>> -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff'
>>
>> We can support signed integers:
>>
>> -z 'dead-reloc-in-nonalloc=.debug_ranges=...
2020 Aug 05
3
Switch to ld.bfd tombstone behavior by default
...fd' semantics may get stale if GNU ld updates its behaviors.
> > >>
> > >> We can also take it from another perspective, do the opt-in options look
> > >> intimidating just because they are too long?
> > >>
> > >> -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe'
> > >> -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe'
> > >> -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff'
> > >>
> > >> We can support signed integers:
> > >>
>...
2020 Aug 05
2
Switch to ld.bfd tombstone behavior by default
...ehaviors.
> > > > >>
> > > > >> We can also take it from another perspective, do the opt-in
> options look
> > > > >> intimidating just because they are too long?
> > > > >>
> > > > >> -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe'
> > > > >> -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe'
> > > > >> -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff'
> > > > >>
> > > > >> We can support...
2020 Aug 05
1
Switch to ld.bfd tombstone behavior by default
...t;
> >> > > > >> We can also take it from another perspective, do the opt-in
> options look
> >> > > > >> intimidating just because they are too long?
> >> > > > >>
> >> > > > >> -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe'
> >> > > > >> -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe'
> >> > > > >> -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff'
> >> > > > >>
> >> >...
2020 Jul 29
2
Switch to ld.bfd tombstone behavior by default
Created https://reviews.llvm.org/D84825 to be used for release/11.x
I haven't seen a strong argument for changing other .debug_* but in
any case I don't want to continue debating on this topic.
* .debug_ranges & .debug_loc: -2 (lld<11: 0+addend)
* .debug_*: 0 (lld<11: 0+addend, lld HEAD: -1)
On Mon, Jul 27, 2020 at 12:47 PM David Blaikie <dblaikie at gmail.com> wrote:
2020 May 31
2
Range lists, zero-length functions, linker gc
...and .debug_loc of using -2. Though I'd
worry a bit about more open-ended use cases for the non-debug
sections. At least for the debug sections we have a pretty good idea
of which consumers to go and talk to/test with, etc.
> we can add a more generic option
>
> -z undef-address-in-nonalloc=-1
>
> Applying to every relocation referencing an undefined symbol in a
> non-SHF_ALLOC section. Let -1 be the default value to make .debug_*
> (excluding .debug_ranges and .debug_loc) happy.
If we end up blessing it as part of the DWARF spec, we probably
wouldn't want it to be us...
2020 May 31
3
Range lists, zero-length functions, linker gc
...pping with the [0, length) ranges created
by dead code with gold/lld - but I'm not sure if he has a use case for
literal zero, or just "low but non-zero". Hopefully he can weigh in
here.
> >> we can add a more generic option
> >>
> >> -z undef-address-in-nonalloc=-1
> >>
> >> Applying to every relocation referencing an undefined symbol in a
> >> non-SHF_ALLOC section. Let -1 be the default value to make .debug_*
> >> (excluding .debug_ranges and .debug_loc) happy.
> >
> >If we end up blessing it as part of the...
2020 May 29
2
Range lists, zero-length functions, linker gc
On Fri, May 29, 2020 at 2:20 PM Robinson, Paul <paul.robinson at sony.com> wrote:
>
>
>
> > -----Original Message-----
> > From: David Blaikie <dblaikie at gmail.com>
> > Sent: Friday, May 29, 2020 5:00 PM
> > To: Robinson, Paul <paul.robinson at sony.com>
> > Cc: Fangrui Song <maskray at google.com>; Alexey Lapshin
> >
2020 Jul 17
2
Switch to ld.bfd tombstone behavior by default
>Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>:
>
>On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song < maskray at google.com > wrote:
>>
>> Thanks for the write-up!
>>
>> On 2020-07-16, David Blaikie wrote:
>> >In short: Perhaps we should switch lld to the bfd-style tombstoning
>> >behavior for a release or