[lldb-dev] breakpoint command

[Greg Clayton]

On Jun 18, 2013, at 6:46 PM, Michael Sartain <mikesart at valvesoftware.com> wrote:

> On Mon, Jun 17, 2013 at 2:33 PM, Greg Clayton <gclayton at apple.com> wrote:
> The "symbol.st_info" is in bits 7:0 of the flags, and the "symbol.st_other" is in bits 15:8. So the flags are:
> 
> 0x00000002 __printf     STB_LOCAL  | STT_FUNC
> 0x00000012 _IO_printf   STB_GLOBAL | STT_FUNC
> 0x00000012 printf       STB_GLOBAL | STT_FUNC
> 
> So there isn't much to be able to do with these symbols. Does anyone know why we have 3 symbols? Are these just aliases? Is there anyway to know that we should use "printf" by inspecting any other sections?
> 
> The printf libc source code looks like this:
> 
>   24 #undef printf
> ...
>   28 int
>   29 __printf (const char *format, ...)
> ...
>   41 #undef _IO_printf
>   42 ldbl_strong_alias (__printf, printf);
>   43 /* This is for libg++.  */
>   44 ldbl_strong_alias (__printf, _IO_printf);
> 
> So yes, there are two strong aliases and one local symbol. gdb seems to prefer the local one when running stacktraces and doing "disassemble printf" or "disassemble _IO_printf". I'll investigate this further though.

Sounds like showing __printf is ok them since this matches the sources.

>  
> I checked out the line table for printf and found that there is indeed no "prologue_end" marker in the line table state machine, so we are setting a breakpoint on the second line table entry in the sequence which maps to 0x0000000000053864 as we saw in your previous output (which was slid to 0x7f961e2a2864). So everything is working as expected here given the information we have.
> 
> If we have no prologue_end marker, would it make sense to not skip anything?

I agree with Jim here and I would vote to still try and skip something. The strongest reason I have for this recommendation is that the debug info for args and locals _relies_ on being past the prologue, and doesn't describe the location correctly for the arguments and locals in the prologue. So when users set a breakpoint on "printf" and they stop there, all variable information is usually bogus until the prologue has been executed. Users don't like seeing garbage values (they file bugs) and then stepping over the first line and then saying "now the variables are correct".