Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <53557463.2050202@midipix.org>
Date: Mon, 21 Apr 2014 15:41:23 -0400
From: "writeonce@...ipix.org" <writeonce@...ipix.org>
To: musl@...ts.openwall.com
Subject: _start(ldso) & _start(crt)

Greetings,

When running a dynamically linked program, the general control flow is

     _start(ldso/{arch}/start.s) --> __dynlink --> _start(crt) --> 
__libc_start_main --> main()

When asking gdb to set up a breakpoint at _start (b _start), gdb's 
confirmation message shows the address of _start(crt), but it then 
breaks at _start(ldso), which is actually what I want.  It then later 
also breaks at _start(crt).

If gdb decided to only break at the executable's _start, then I believe 
there would be no way to request a break at the interpreter's (ldso)  
_start routine, since the address of ldso's _start is not known prior to 
execution.

I am not sure whether this is a good-enough motivation to rename ldso's 
start to _ldso_start (and set libc.so's entry point accordingly), or 
whether we could simply count on gdb and other debuggers to continue to 
do the "right thing" by breaking at the earlier _start of the two.  For 
one thing, setting a breakpoint at __dynlink provides pretty much the 
same debugging ability as with _start(ldso), and does not require any 
changes.  Any thoughts?

Kind regards,
zg

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.