Displaying 7 results from an estimated 7 matches for "relocoffset".
Did you mean:
reloc_offset
2012 Mar 22
2
[LLVMdev] Sorting relocation entries
...int Index;
> + unsigned Type;
> + const MCSymbol *Symbol;
> + uint64_t r_addend;
> + const MCFixup *fixup;
> +
> + ELFRelocationEntry()
> + : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {}
> +
> + ELFRelocationEntry(uint64_t RelocOffset, int Idx,
> + unsigned RelType, const MCSymbol *Sym,
> + uint64_t Addend, const MCFixup *Fixup)
> + : r_offset(RelocOffset), Index(Idx), Type(RelType),
> + Symbol(Sym), r_addend(Addend), fixup(Fixup) {}
> +
> + // Support...
2012 Mar 23
0
[LLVMdev] Sorting relocation entries
...d Type;
>> + const MCSymbol *Symbol;
>> + uint64_t r_addend;
>> + const MCFixup *fixup;
>> +
>> + ELFRelocationEntry()
>> + : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {}
>> +
>> + ELFRelocationEntry(uint64_t RelocOffset, int Idx,
>> + unsigned RelType, const MCSymbol *Sym,
>> + uint64_t Addend, const MCFixup *Fixup)
>> + : r_offset(RelocOffset), Index(Idx), Type(RelType),
>> + Symbol(Sym), r_addend(Addend), fixup(Fixup) {}
>> +
&...
2012 Mar 23
1
[LLVMdev] Sorting relocation entries
...MCSymbol *Symbol;
>>> + uint64_t r_addend;
>>> + const MCFixup *fixup;
>>> +
>>> + ELFRelocationEntry()
>>> + : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {}
>>> +
>>> + ELFRelocationEntry(uint64_t RelocOffset, int Idx,
>>> + unsigned RelType, const MCSymbol *Sym,
>>> + uint64_t Addend, const MCFixup *Fixup)
>>> + : r_offset(RelocOffset), Index(Idx), Type(RelType),
>>> + Symbol(Sym), r_addend(Addend), fixup(Fixup)...
2012 Mar 22
0
[LLVMdev] Sorting relocation entries
Here is the patch.
On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote:
> Hi Jim,
>
> Yes, the relocation entries have to be reordered so that the
> got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation
> table. As a result, relocations can appear in a different order than
> the instructions that they're for.
>
> For
2018 Aug 31
2
PDB questions
...n
here?
1. There appears to be 8 bytes before every LineFragmentHeader. Here's some
of my own debug output, which matches llvm-pdbutil's output. You can see it
says "unknown bytes: ...".
read C13 line info 136720 bytes
unknown bytes: f2 00 00 00 60 00 00 00
LineFragmentHeader{ .RelocOffset = 0, .RelocSegment = 5, .Flags =
LineFlags{ .LF_HaveColumns = true, .unused = 0 }, .CodeSize = 52 }
has column: true
LineBlockFragmentHeader{ .NameIndex = 0, .NumLines = 6, .BlockSize = 84 }
LineNumberEntry{ .Offset = 0, .Flags = 101 } Flags{ .Start = 101, .End =
17, .IsStatement = false }
<snip...
2012 Mar 22
2
[LLVMdev] Sorting relocation entries
Hi Jim,
Yes, the relocation entries have to be reordered so that the
got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation
table. As a result, relocations can appear in a different order than
the instructions that they're for.
For example, in this code, the post-RA scheduler inserts an
instruction with relocation %got(body_ok) between %got(scope_top) and
%lo(scope_top).
$ cat
2018 Aug 31
2
PDB questions
...LineFragmentHeader. Here's
>> some of my own debug output, which matches llvm-pdbutil's output. You can
>> see it says "unknown bytes: ...".
>>
>> read C13 line info 136720 bytes
>> unknown bytes: f2 00 00 00 60 00 00 00
>> LineFragmentHeader{ .RelocOffset = 0, .RelocSegment = 5, .Flags =
>> LineFlags{ .LF_HaveColumns = true, .unused = 0 }, .CodeSize = 52 }
>> has column: true
>> LineBlockFragmentHeader{ .NameIndex = 0, .NumLines = 6, .BlockSize = 84 }
>> LineNumberEntry{ .Offset = 0, .Flags = 101 } Flags{ .Start = 101, .End =...