search for: fixupkind

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

Hi everyone. In ARMAsmBackend.cpp, in routine DarwinARMAsmBackend::ApplyFixup() there is a curious call to getFixupKindNumBytes() - which can return 1,2, 3, or 4 depending upon the FixupKind The code in ApplyFixup() seems to be lifted from the X86. AFAIK, the initial Fixup.Offset() is always divisible by 4, at least for ARM mode - i.e. it is always at the instruction boundary. it looks like adjustFixupValue() is...

Hi, I would like to use a MCFixup to encode the distance in number of bytes from an instruction to the end of the .text section. Is there an existing MCFixup type I can use for this? If not, does anyone have any suggestions for how to add a new MCFixup type that will do this? Thanks, Tom

...OS, and is usually a superset** of what the native object format (Mach-O, ELF, COFF) can represent. The "pure" backend defines a hard (but non-stable) object file format which is more or less a direct encoding of the native MC APIs (it is not stable, so it can directly encode things like FixupKind enum values). I don't have a name for this format, so for now I will call it FOO. The "MC-JIT" then becomes something more like a "FOO-JIT". It is architected as a consumer of "FOO" object files over time. The basic architecture is quite simple: (a) Load a modul...

...erset** of what the native object format > (Mach-O, ELF, COFF) can represent. > > The "pure" backend defines a hard (but non-stable) object file format > which is more or less a direct encoding of the native MC APIs (it is > not stable, so it can directly encode things like FixupKind enum > values). > > I don't have a name for this format, so for now I will call it FOO. > > The "MC-JIT" then becomes something more like a "FOO-JIT". It is > architected as a consumer of "FOO" object files over time. The basic > architecture i...

...erset** of what the native object format > (Mach-O, ELF, COFF) can represent. > > The "pure" backend defines a hard (but non-stable) object file format > which is more or less a direct encoding of the native MC APIs (it is > not stable, so it can directly encode things like FixupKind enum > values). > > I don't have a name for this format, so for now I will call it FOO. > > The "MC-JIT" then becomes something more like a "FOO-JIT". It is > architected as a consumer of "FOO" object files over time. The basic > architecture i...

...; object format (Mach-O, ELF, COFF) can represent. > > > > The "pure" backend defines a hard (but non-stable) object file > > format which is more or less a direct encoding of the native MC > > APIs (it is not stable, so it can directly encode things like > > FixupKind enum values). > > > > I don't have a name for this format, so for now I will call it FOO. > > > > The "MC-JIT" then becomes something more like a "FOO-JIT". It is > > architected as a consumer of "FOO" object files over time. The basic...

...ject format > > (Mach-O, ELF, COFF) can represent. > > > > The "pure" backend defines a hard (but non-stable) object file format > > which is more or less a direct encoding of the native MC APIs (it is > > not stable, so it can directly encode things like FixupKind enum > > values). > > > > I don't have a name for this format, so for now I will call it FOO. > > > > The "MC-JIT" then becomes something more like a "FOO-JIT". It is > > architected as a consumer of "FOO" object files over ti...

.../lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp index 8a9077c..e3cceca 100644 --- a/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp +++ b/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp @@ -19,7 +19,11 @@ #include "llvm/MC/MCELFObjectWriter.h" #include "llvm/MC/MCFixupKindInfo.h" #include "llvm/MC/MCObjectWriter.h" +#include "llvm/MC/MCSectionMachO.h" +#include "llvm/MC/MCSection.h" +#include "llvm/MC/SectionKind.h" #include "llvm/Support/ELF.h" +#include "llvm/Support/MachO.h" #include "llvm/Su...

...e object format > > (Mach-O, ELF, COFF) can represent. > > > > The "pure" backend defines a hard (but non-stable) object file format > > which is more or less a direct encoding of the native MC APIs (it is > > not stable, so it can directly encode things like FixupKind enum > > values). > > > > I don't have a name for this format, so for now I will call it FOO. > > > > The "MC-JIT" then becomes something more like a "FOO-JIT". It is > > architected as a consumer of "FOO" object files over time....

...> > (Mach-O, ELF, COFF) can represent. >> > >> > The "pure" backend defines a hard (but non-stable) object file format >> > which is more or less a direct encoding of the native MC APIs (it is >> > not stable, so it can directly encode things like FixupKind enum >> > values). >> > >> > I don't have a name for this format, so for now I will call it FOO. >> > >> > The "MC-JIT" then becomes something more like a "FOO-JIT". It is >> > architected as a consumer of "FOO"...