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. > > 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... Jim > > Thanks Greg. > -Mike > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
