search for: assignaddresses

...r. The issue is not with the > patch, is with the existing infrastructure that uses a completely > different representation for linker scripts and non linker scripts. > > What I think is needed is for the writer to create a dummy "script" > and use what is now LinkerScript::assignAddresses. That "script" would > > * Contain only OutputSectionCommand. > * All string manipulations would have been moved before assignAddress. > * All the orphan handling would have been made explicit before > assignAddress. > * Each OutputSectionCommand would contain just a Inp...

On 6 April 2017 at 07:01, Peter Smith <peter.smith at linaro.org> wrote: > My understanding is that this would be (initially) limited to > fabricating enough linker script commands such that we could replace: > fixSectionAlignments() > assignAddresses() > Script->processNonSectionCommands() > > With something like: > Script->assignAddresses() // Could be done multiple times > Script->processNonSectionCommands() // This should only be done once Correct. > In theory all the other __start and __end symbols could still b...

This RFC is primarily to support the review of the range extension thunks implementation of lld. This concerns ARM and Mips as all of the thunk creation step is skipped over if the target doesn't need thunks. Mips LA25 Thunks are not range extension Thunks but these are generated using the same code, I've kept the behaviour the same as it is now, although the implementation is obviously

...he offset in the OutputSection altered by the addition of thunks. In particular scanRelocs() calculates the offset in the OutputSection of some relocations. We would need to find alternative ways of handling these cases so that they could either survive thunk creation or be patched up afterwards. - assignAddresses() will need to run at least twice if thunks are created. At least once to give the thunk creation the caller and callee addresses, and at least once after all thunks have been created. There is an alternative design that only uses estimates of caller and callee address to decide if a thunk is need...

...addition of thunks. In particular >> scanRelocs() calculates the offset in the OutputSection of some >> relocations. We would need to find alternative ways of handling these >> cases so that they could either survive thunk creation or be patched >> up afterwards. >> - assignAddresses() will need to run at least twice if thunks are >> created. At least once to give the thunk creation the caller and >> callee addresses, and at least once after all thunks have been >> created. >> >> There is an alternative design that only uses estimates of caller and...