[lldb-dev] breakpoint command
jingham at apple.com
jingham at apple.com
Tue Jun 18 18:58:14 PDT 2013
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.
> 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 don't know what more recent gcc's do, but they used to omit the prologue_end marker, and instead use the convention that the first line table entry for the function is the beginning of the function, and the second is the end of the prologue. gdb has relied on that for a long long time (in absence of the prologue_end and back to the stabs days when there was no such thing.) So not skipping the prologue in this case seems like throwing the baby out with the bath water. Better would be to get your compiler to get it right...
> Thanks Greg.
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
More information about the lldb-dev