Displaying 6 results from an estimated 6 matches for "soryr".
Did you mean:
sorry
2004 Oct 15
0
Success at last and thanks!
Hi!
Soryr about being a whiner, not enough sleep and too much frustration
don''t become too well.
In any case, I have succeeded with the shaping now. The problem seems
to have been twofold. First of all I had the rate too high for the actual
throughput. We have a 1mbit connection to the internet...
2020 May 29
2
Range lists, zero-length functions, linker gc
...t; (I managed to lobby the ideas to GNU ld. GNU ld from binutils 2.35
> > onwards will have mostly compatible semantics with LLD)
> >
> > There is a cost fragmenting a .debug_* section: sizeof(Elf64_Shdr)=64 ->
> > each section takes 64 bytes in the section header table.
Soryr, I missed a step here - you're talking about the cost to
fragmenting .debug_* sections as an alternative to choosing a special
address value to resolve for dead code? (by removing the DWARF that
refers to the dead code, uinstead of keeping it and having to write a
special address value into it?...
2020 May 29
2
Range lists, zero-length functions, linker gc
...> > > > onwards will have mostly compatible semantics with LLD)
> > > >
> > > > There is a cost fragmenting a .debug_* section: sizeof(Elf64_Shdr)=64
> > ->
> > > > each section takes 64 bytes in the section header table.
> >
> > Soryr, I missed a step here - you're talking about the cost to
> > fragmenting .debug_* sections as an alternative to choosing a special
> > address value to resolve for dead code? (by removing the DWARF that
> > refers to the dead code, uinstead of keeping it and having to write a...
2020 May 31
2
Range lists, zero-length functions, linker gc
...le semantics with LLD)
> >> > > >
> >> > > > There is a cost fragmenting a .debug_* section: sizeof(Elf64_Shdr)=64
> >> > ->
> >> > > > each section takes 64 bytes in the section header table.
> >> >
> >> > Soryr, I missed a step here - you're talking about the cost to
> >> > fragmenting .debug_* sections as an alternative to choosing a special
> >> > address value to resolve for dead code? (by removing the DWARF that
> >> > refers to the dead code, uinstead of keepin...
2020 May 31
3
Range lists, zero-length functions, linker gc
...; >
> >> >> > > > There is a cost fragmenting a .debug_* section: sizeof(Elf64_Shdr)=64
> >> >> > ->
> >> >> > > > each section takes 64 bytes in the section header table.
> >> >> >
> >> >> > Soryr, I missed a step here - you're talking about the cost to
> >> >> > fragmenting .debug_* sections as an alternative to choosing a special
> >> >> > address value to resolve for dead code? (by removing the DWARF that
> >> >> > refers to the de...
2020 May 29
4
Range lists, zero-length functions, linker gc
On 2020-05-28, David Blaikie wrote:
>On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com>
>wrote:
>
>> As has been mentioned elsewhere, Sony generally fixes up references from
>> debug info to stripped functions (of any length) using -1, because that’s a
>> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base
>>