search for: fileoffsets

Displaying 7 results from an estimated 7 matches for "fileoffsets".

Did you mean: fileoffset
2013 Sep 17
5
[LLVMdev] [lld] Handling non SHF_ALLOC sections.
Debug info linking is currently broken due to how we handle reading and laying out non SHF_ALLOC sections. I posted a patch that partially fixes this, but it's both the wrong approach and doesn't handle multiple input files with debug info (wrong relocation values). The first issue is representing non SHF_ALLOC atoms in the Atom model. We currently don't have a type for this, and
2012 Jan 23
3
[LLVMdev] 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()
2007 Feb 02
5
reading very large files
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
2013 Sep 17
0
[LLVMdev] [lld] Handling non SHF_ALLOC sections.
Hi Michael, On 9/16/2013 7:23 PM, Michael Spencer wrote: > Debug info linking is currently broken due to how we handle reading and > laying out non SHF_ALLOC sections. I posted a patch that partially fixes > this, but it's both the wrong approach and doesn't handle multiple input > files with debug info (wrong relocation values). > > The first issue is representing non
2013 Sep 17
0
[LLVMdev] [lld] Handling non SHF_ALLOC sections.
On Mon, Sep 16, 2013 at 8:23 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > Debug info linking is currently broken due to how we handle reading and > laying out non SHF_ALLOC sections. I posted a patch that partially fixes > this, but it's both the wrong approach and doesn't handle multiple input > files with debug info (wrong relocation values). > > The
2013 Sep 17
1
[LLVMdev] [lld] Handling non SHF_ALLOC sections.
On Mon, Sep 16, 2013 at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Michael, > > > On 9/16/2013 7:23 PM, Michael Spencer wrote: > >> Debug info linking is currently broken due to how we handle reading and >> laying out non SHF_ALLOC sections. I posted a patch that partially fixes >> this, but it's both the wrong approach and
2012 Jan 23
0
[LLVMdev] ELFObjectFile changes, llvm-objdump showing 'wrong' values?
Hi, I would like to examine the implications you mention in more detail. (1) Symbol address According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, st_value is an offset from the beginning of the section that st_shndx identifies." (*) Therefore, when queried about a symbol's