> So my problem was caused by the function descriptor not being visible > when I printed the pointer to the function with gdb. Why isn't gdb being > fixed so that the function descriptor is visible?
While I agree that being able to display the descriptor would be a useful feature, implementing it isn't that straight forward. It leads to all sort of edge conditions, I'll note three of them below. Can I suggest sending further comments to [EMAIL PROTECTED] or recording the feature request with a bug report in http://sources.redhat.com/gdb/bugs: enjoy, Andrew -- The descriptor isn't visible from C so there is no C construct available that lets you access it. vis: (top-gdb) print main $1 = {int (int, char **)} 0x1803458 <main> (top-gdb) print &main $2 = (int (*)(int, char **)) 0x1803458 <main> (top-gdb) print *(&main) $3 = {int (int, char **)} 0x1803458 <main> A mechanism outside of the normal C expression / type system would be needed. -- Adding to the fun, consider the code: extern void foo (void); long bar = &foo; and the GDB sequence: (gdb) print bar (gdb) print &foo For GDB to print identical values for ``bar'' and ``&foo'' it needs to find, in target memory, the descriptor for ``&foo'' that GCC created. GDB does try to do this. -- Finally, GCC has this wonderful feature (not) where the user can specify: foo + 10 GCC converts it to something like: &foo + 10 For a descriptor based ABI, is turns out to be pretty meaningless. It is a random pointer into target data space. GDB doesn't emulate this since it leads to commands such as: (gdb) disassemble foo foo + 10 being meaningless. . _______________________________________________ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
