search for: atomsect

...s representing non SHF_ALLOC atoms in the Atom model. We currently don't have a type for this, and DefinedAtom.cpp makes assumptions about the permissions of an Atom based on their type, so it's hard to use an existing type. The next problem is in the ELF writer. It currently cannot handle AtomSections that are not in a segment as file offsets and addresses are never set. This means that assignOffsets is not called, and that the atoms within are never added to the _atomToAddressMap. However, we can't just add them to that map with their virtual address, as they don't have a virtual ad...

...y). The advantage of this approach would be that Garbage collection would remove all the unneeded references automatically when the definedatom is removed. I think Nick also mentioned about a similiar way a while back. > The next problem is in the ELF writer. It currently cannot handle > AtomSections that are not in a segment as file offsets and addresses are > never set. This means that assignOffsets is not called, and that the atoms > within are never added to the _atomToAddressMap. However, we can't just add > them to that map with their virtual address, as they don't ha...

...one using result from the first step, > repeat that for the third relocations and only at the end check the > final result on overflow and apply it to the location. My current idea > is to allow a target specific code to handle the loop over atom's > references now hardcoded in the `AtomSection<ELFT>::write` method. > >> On Sun, Feb 8, 2015 at 3:21 AM, Nick Kledzik <kledzik at apple.com><mailto:kledzik at apple.com> wrote: >> Simon, >> >> Sounds like the instruction relocating is so complicated that ELF requires up to three relocation record...

...atoms in the Atom model. We > currently don't have a type for this, and DefinedAtom.cpp makes assumptions > about the permissions of an Atom based on their type, so it's hard to use > an existing type. > > The next problem is in the ELF writer. It currently cannot handle > AtomSections that are not in a segment as file offsets and addresses are > never set. This means that assignOffsets is not called, and that the atoms > within are never added to the _atomToAddressMap. However, we can't just add > them to that map with their virtual address, as they don't ha...

...; removed. > > I think Nick also mentioned about a similiar way a while back. You can't just parse it by byte ranges and pull some out. You would actually need to parse the DWARF and rewrite it. > > > The next problem is in the ELF writer. It currently cannot handle >> AtomSections that are not in a segment as file offsets and addresses are >> never set. This means that assignOffsets is not called, and that the atoms >> within are never added to the _atomToAddressMap. However, we can't just >> add >> them to that map with their virtual address,...

...step, >>> repeat that for the third relocations and only at the end check the >>> final result on overflow and apply it to the location. My current idea >>> is to allow a target specific code to handle the loop over atom's >>> references now hardcoded in the `AtomSection<ELFT>::write` method. >>> >>>> On Sun, Feb 8, 2015 at 3:21 AM, Nick Kledzik <kledzik at apple.com> >> <kledzik at apple.com> wrote: >>>> Simon, >>>> >>>> Sounds like the instruction relocating is so complicated that...

Hi, I need an advice on implementation of a very specific kind of relocations used by MIPS N64 ABI. As usual the main problem is how to pass target specific data over Native/YAML conversion barrier. In this ABI relocation record r_info field in fact consists of five subfields: * r_sym - symbol index * r_ssym - special symbol * r_type3 - third relocation type * r_type2 - second relocation type