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