search for: fileoffset

...ithin 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 address. We need to use the symbol value, which is the offset into the section. My current hack to fix this is to call assignVirtualAddresses(-fileoffset) and then explicitly added them to the _atomToAddressMap. Any ideas for the proper fix here? - Michael Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130916/956a47ec/attachment.html>

Hi all, I'm using the MC framework for a project, and while updating to latest trunk (r148672) encountered the following issue: It seems that SymbolRef::getAddress and SymbolRef::getFileOffset have been changed to add the symbol's offset to the offset of the containing section? This has the following implications: To get the /actual/ fileoffset, I now need to do: Symbol.getFileOffset() - ContainingSection.getFileOffset() And to get the address relative to the section, I do: Symbol....

Hi all, I have a large file (1.8 GB) with 900,000 lines that I would like to read. Each line is a string characters. Specifically I would like to randomly select 3000 lines. For smaller files, what I'm doing is: trs <- scan("myfile", what= character(), sep = "\n") trs<- trs[sample(length(trs), 3000)] And this works OK; however my computer seems not able to handle

...d to the _atomToAddressMap. However, we can't just add > them to that map with their virtual address, as they don't have a virtual > address. We need to use the symbol value, which is the offset into the > section. My current hack to fix this is to call > assignVirtualAddresses(-fileoffset) and then explicitly added them to the > _atomToAddressMap. > > Any ideas for the proper fix here? There is a way that we can handle this without lot of tweaks. a) Assign the debug sections part of a linker internal segment(the segment would not appear in the output file), hasOutputSegme...

...d to the _atomToAddressMap. However, we can't just add > them to that map with their virtual address, as they don't have a virtual > address. We need to use the symbol value, which is the offset into the > section. My current hack to fix this is to call > assignVirtualAddresses(-fileoffset) and then explicitly added them to the > _atomToAddressMap. > > Any ideas for the proper fix here? > This seems like a problem that will be solved along the way of implementing `ld -r`, so the "proper" solution will probably be something in the general direction of `ld -r`....

...However, we can't just >> add >> them to that map with their virtual address, as they don't have a virtual >> address. We need to use the symbol value, which is the offset into the >> section. My current hack to fix this is to call >> assignVirtualAddresses(-**fileoffset) and then explicitly added them to >> the >> _atomToAddressMap. >> >> Any ideas for the proper fix here? >> > There is a way that we can handle this without lot of tweaks. > > a) Assign the debug sections part of a linker internal segment(the segment > woul...

...v] ELFObjectFile changes, llvm-objdump showing 'wrong' > values? > > Hi all, > > I'm using the MC framework for a project, and while updating to latest trunk > (r148672) encountered the following issue: > > It seems that SymbolRef::getAddress and SymbolRef::getFileOffset have > been changed to add the symbol's offset to the offset of the containing > section? > > This has the following implications: > > To get the /actual/ fileoffset, I now need to do: > Symbol.getFileOffset() - ContainingSection.getFileOffset() And to get the > addres...