--- Additional Comments From dzidzitop at lavabit dot com 2010-04-22 13:02
---
Created an attachment (id=4747)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=4747action=view)
executable which re-produces the bug
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11527
--- Additional Comments From hjl dot tools at gmail dot com 2010-04-22
18:13 ---
__libc_start_main isn't defined in ddd:
[...@gnu-6 tmp]$ nm ddd | grep __libc_start_main
U __libc_start_main@@GLIBC_2.0
[...@gnu-6 tmp]$
--
What|Removed
--- Additional Comments From dzidzitop at lavabit dot com 2010-04-22 18:42
---
What is ddd? And why backtrace_symbols correctly recognises the function?
--
What|Removed |Added
--- Additional Comments From dzidzitop at lavabit dot com 2010-04-22 18:45
---
Ah, ddd is the name of the executable.
__libc_start_main could be found within the binary with ease. Dunno what is nm,
but simple search for __libc_start_main in text editor returns something.
--
--- Additional Comments From dzidzitop at lavabit dot com 2010-04-22 20:56
---
Ok, probably just by analysing the executable statically (i.e. when it is not
loaded into the memory) it is impossible to resolve dynamically linked
functions: no section is actually created for them within
