This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Revamp sniffer; Was: [obish?sym;rfa:doc] Wire up vsyscall


If I understood your description correctly, the source of the current
problem scenario is that glibc supplies CFI for the trampoline code
(__restore_rt), but that CFI is not written to match how the peculiar frame
will look.  So, glibc could change its CFI to use the same hack that the
x86 kernel CFI uses for the analogous code, or it could omit that CFI
entirely and expect gdb to recognize the name and/or instruction sequence.

My inclination is to omit the CFI because that's how it is on x86 in the
analogous case.  (If in future x86-64 has kernel-supplied trampoline code,
we expect it will be in the form of a vsyscall DSO that supplies CFI via
existing glibc support, as on x86.  In that case, the CFI will use the same
sort of hack as the x86 CFI does.)  Would that make things better?

Ah! I guess it would help. GDB will still need to do something more immediate though.


Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]