| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
contrib/ instead.
Notes:
svn path=/projects/elftoolchain/; revision=260698
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
representations of ELF types.
The ELF(3) API allows applications to request a conversion that is
`in-place', i.e., with source and destinations data buffers being
the same. However, the file and memory sizes of ELF sections that
have additional internal structure, such as those of type `Elf_Note',
or `Elf_GNU_Hash_Header', can be determined only known after the
type-specific headers that comprise the first few words in these
sections are read and translated.
Pass in the size of destination buffer to type translation routines
in "libelf_convert.m4" and have these routines return an error code
if the translated data would not fit inside the destination buffer.
Obtained from: elftoolchain
MFC after: 1 month
Notes:
svn path=/head/; revision=210338
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
members of the ELF Executable Header inside the library-private
`struct _Elf' descriptor and only update the underlying Elf{32,64}_Ehdr
structure on an elf_update(3) call. These fields of the Ehdr
structure are technically `out of bounds' for an application program
per the ELF(3) API, but we've seen applications that initialize
a new Ehdr structure using memcpy(), messing up the library's
invariants. [1]
Implement elf_getphnum() and handle ELF objects with more than
64K program header table entries.
Reported by: jb [1]
Notes:
svn path=/head/; revision=165535
|
|
|
Bump __FreeBSD_version.
Reviewed by: jb
Notes:
svn path=/head/; revision=164190
|
