Hi all,
The attached patch builds off of previous work on ELF64. Main aspects:
- Introduces ELFHeader.h and ELFHeader.cpp. These files provide
"generic" definitions for the 32/64 bit elf entries. Each object
(section header, symbol table entry, etc) provides a parsing method
that can extract 32 or 64 bit data given a DataExtractor.
- ObjectFileELF is now a generic elf parser. It implements the
ObjectFile protocol and can interrogate 32 or 64 bit elf files
using the same code.
- ObjectFileELF32 and ObjectFile64 are thin wrappers atop
ObjectFileELF and provide the plugin interface.
- With this patch and LLVM commit r108221 we can remove our local
elf.h.
As this patch is intrusive, to apply one must:
pushd source/Plugins/ObjectFile/ELF/
svn rm ObjectFileELF.h ObjectFileELF.cpp
svn copy ObjectFileELF64.h ObjectFileELF.h
svn copy ObjectFileELF64.cpp ObjectFileELF.cpp
popd
patch -p0 < elf-2010-07-13.patch
Take care,
Steve
elf-2010-07-13.patch (100 KB)
- ObjectFileELF32 and ObjectFile64 are thin wrappers atop
ObjectFileELF and provide the plugin interface.
If the code is all shared, what's the justification at this point for
keeping the ELF32 and ELF64 readers as separate plugins? It seems
like it would be just as easy to have a unified ELF reader.
- With this patch and LLVM commit r108221 we can remove our local
elf.h.
Make sure you don't commit this until the llvm.zip is updated with
that commit. Also, the XCode project will need to be updated, but it
should be okay to just let someone update that post-commit.
+bool
+ELFHeader::MagicBytesMatch(const uint8_t *magic)
+{
+ if (magic != NULL)
+ return memcmp(magic, ElfMagic, strlen(ElfMagic)) == 0;
+ return false;
+}
Is it actually possible for magic to be null here? Same applies to
ELFHeader::AddressSizeInBytes.
-Eli
Hi Eli,
Eli Friedman <eli.friedman@gmail.com> writes:
- ObjectFileELF32 and ObjectFile64 are thin wrappers atop
ObjectFileELF and provide the plugin interface.
If the code is all shared, what's the justification at this point for
keeping the ELF32 and ELF64 readers as separate plugins? It seems
like it would be just as easy to have a unified ELF reader.
There is no technical justification -- just a meta-level "conceptual"
difference. But I think you are right, will rework the patch to remove
ObjectFileELF32/64.
- With this patch and LLVM commit r108221 we can remove our local
elf.h.
Make sure you don't commit this until the llvm.zip is updated with
that commit. Also, the XCode project will need to be updated, but it
should be okay to just let someone update that post-commit.
Right. Thanks for the reminder. I can remove reliance an
llvm/Support/ELF.h for now and use the local elf.h until a new snapshot
is taken.
+bool
+ELFHeader::MagicBytesMatch(const uint8_t *magic)
+{
+ if (magic != NULL)
+ return memcmp(magic, ElfMagic, strlen(ElfMagic)) == 0;
+ return false;
+}
Is it actually possible for magic to be null here? Same applies to
ELFHeader::AddressSizeInBytes.
I suppose it is possible that the plugin could be passed an empty
DataBuffer. That being said, this check belongs in the CreateInstance
function. Will fix.
Thanks for looking this over!
Steve
Hi Eli,
Eli Friedman <eli.friedman@gmail.com> writes:
- ObjectFileELF32 and ObjectFile64 are thin wrappers atop
ObjectFileELF and provide the plugin interface.
If the code is all shared, what's the justification at this point for
keeping the ELF32 and ELF64 readers as separate plugins? It seems
like it would be just as easy to have a unified ELF reader.
There is no technical justification -- just a meta-level "conceptual"
difference. But I think you are right, will rework the patch to remove
ObjectFileELF32/64.
That sounds good.
- With this patch and LLVM commit r108221 we can remove our local
elf.h.
Make sure you don't commit this until the llvm.zip is updated with
that commit. Also, the XCode project will need to be updated, but it
should be okay to just let someone update that post-commit.
Right. Thanks for the reminder. I can remove reliance an
llvm/Support/ELF.h for now and use the local elf.h until a new snapshot
is taken.
No worries, leave this as is and I will update the llvm.zip with a today's llvm sources. Just watch for the llvm.zip file to be updated before you commit your changes (or post your patch if you don't have commit access).
+bool
+ELFHeader::MagicBytesMatch(const uint8_t *magic)
+{
+ if (magic != NULL)
+ return memcmp(magic, ElfMagic, strlen(ElfMagic)) == 0;
+ return false;
+}
Is it actually possible for magic to be null here?
magic currently should never be NULL when MagicBytesMatch is called.
Same applies to ELFHeader::AddressSizeInBytes.
Caller (I assume the only caller is the ELF plug-in itself) would need to verify that magic isn't NULL for this.
Hi Greg,
Greg Clayton <gclayton@apple.com> writes:
Steve,
The llvm.zip file has been updated, check in your changes any time!
Comitted revision 108285.
Greg Clayton
Hi Greg,
ELF changes are in revision 108292. Removal of local elf.h is revision
108293.
If needed, could you could tweak the xcode project files for me?
Thanks!
Steve
Greg Clayton <gclayton@apple.com> writes: