elf

Any recommendations for a good cross-platform library for reading ELF file debug information in DWARF format? I'd like to read the DWARF debug info in a Python program. There's a new kid on the block - pyelftools - a pure Python library for parsing the ELF and DWARF formats. Give it a try. It aims to be feature-complete and is currently in active development, so any problems should be handled quickly and enthusiastically :-) Martin v. Löwis The concept of "ELF debug info" doesn't really exist: the ELF specification leaves the content of the .debug section deliberately unspecified. Common debug

I'm working on a nodejs project for school. I wasn't able to install bcrypt with npm so i installed bcrypt-nodejs and the project worked fine yesterday. But today, when I do a "node app" i have this error : /.../node_modules/bcrypt/node_modules/bindings/bindings.js:79 throw e ^ Error: /.../node_modules/bcrypt/build/Release/bcrypt_lib.node: invalid ELF header at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Module.require (module.js:364:17) at require (module.js:380:17) at bindings (/.../node_modules/bcrypt/node_modules/bindings/bindings.js:74:15) at Object.

If I understand correctly, the .bss section in ELF files is used to allocate space for zero-initialized variables. Our tool chain produces ELF files, hence my question: does the .bss section actually have to contain all those zeroes? It seems such an awful waste of spaces that when, say, I allocate a global ten megabyte array, it results in ten megabytes of zeroes in the ELF file. What am I seeing wrong here? Has been some time since i worked with ELF. But i think i still remember this stuff. No, it does not physically contain those zeros. If you look into an ELF file program header, then you

Suppose I have a function like below: # cat 003.c int foo(int a, int b) { return a+b; } And compile it like this: gcc -S 003.c The gets the following assembly result: .file "003.c" .text .globl foo .type foo, @function foo: .LFB2: pushq %rbp .LCFI0: movq %rsp, %rbp .LCFI1: movl %edi, -4(%rbp) movl %esi, -8(%rbp) movl -8(%rbp), %edx movl -4(%rbp), %eax addl %edx, %eax leave ret .LFE2: .size foo, .-foo /* size of the function foo, how to get it?*/ The last line above do get the size of the function. Where does the compiler store the size? Can I get the function's size in some way in my origin C

So I have the following program: int main(){ char* one = "computer"; char two[] = "another"; two[1]='b'; one[1]='b'; return 0; } It segfaults on the line "one[1]='b'" which makes sense because the memory that the pointer "one" points to must be in read only memory. However, the question is why doesn't the line "two[1]='b'" segfault? Looking at the assembly output from gcc: .file "one.c" .section .rodata .LC0: .string "computer" .LC1: .string "another" .text .globl main .type main, @function main: We see that both strings are in the rodata section so they are readonly. So then how come the line

I have a problem linking some shared library with g++. It gives me a warning like: hidden symbol XXX in YYY is referenced by DSO /usr/lib/... I've read some related questions about particular problems, but I want to understand it in a whole - what does this warning mean and what is a cause: What is DSO? What is a hidden symbol? How can it be referenced, if it's hidden? What is a DSO? A DSO is a Dynamic Shared Object , or less formally a shared library . What is a hidden symbol? A hidden symbol is a symbol (i.e. name of function or data object) that has been compiled with hidden linkage , e.g.