On Jun 18, 2013, at 6:46 PM, Michael Sartain <[email protected]> wrote:

> On Mon, Jun 17, 2013 at 2:33 PM, Greg Clayton <[email protected]> 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".


_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to