Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Pedro Alves <palves at redhat dot com>]

On 06/08/2012 02:36 PM, Mark Kettenis wrote:

>> Date: Fri, 08 Jun 2012 14:07:14 +0100
>> From: Pedro Alves <palves@redhat.com>
>>
>> On 06/08/2012 01:38 PM, Jan Kratochvil wrote:
>>> I still do not see why 'main' was not left there as it would not hurt and it
>>> could help.
>>
>> The original patch was trivial, and a one liner.  I preferred not
>> requiring bigger changes and risk needing to require copyright
>> assignment for that patch.  Then, GDB has not been trapping on
>> "main", but on "_start" for static binaries for a long time, so that
>> even feels like a separate "feature" to me.
> 
> The problem here is that "_start" is by no means a standardized name,
> whereas "main" is (although there are some exceptions).


Yes, I've mentioned that myself in this thread.
The solution is then to set the breakpoint at the elf's entry point,
not "_start" literally.

>> I even feel like we could/should drop the "_start/main" fallback
>> from svr4 handling.  It's just historic at this point, as far as I
>> could ascertain.  If those are really needed on some system, then a
>> comment in the code mentioning such system is warranted.
> 
> Please don't do this.  The fallback is useful when bringing up GDB on
> a new platform that decided to use yet another name for the ld.so
> state point "function".  


Oh come on, for bring up, just hack GDB and add "main" or whatever
until you fix things properly.  ;-)

> Or in other cases where for some reason

> placing breakpoints in ld.so doesn't work but putting them in the
> executable itself does work.  I've been in that situation at least a
> couple of times in the past couple of years.


Okay, that'd be for dynamically linked executables.
I'd buy this, but I'd love to hear more about it.  The current fallback
still leaves dlopen out in this case.

-- 
Pedro Alves