Daniel Jacobowitz wrote: > On Sun, Dec 15, 2002 at 01:48:12AM +0100, Michal Ludvig wrote: > >>this long patch provides a fix for a very annoying fact, that GDB on >>x86-64 can't do backtraces from hand-optimized assembler functions (that >>applies for example to glibc's memset, str*, etc as well as to syscall >>wrappers). > > Workaround, really - just for some particular functions... Yes, but still better than nothing ;-) >>My approach to fix this behaviour is based on the fortunate fact, that >>most of those affected glibc's functions don't touch the stack at all, >>so creating an artifical FDE for them is easy. > > Lucky. We can use this to solve a similar problem on i386 but that > will require an actual FDE. I got it by compiling a sample program with 'gcc -S -g -dA'. >>The patch is transparent to architectures that are not prepared to have >>advantage of it and shouldn't hurt anything. > > Great. One big problem: gdbarch.h and gdbarch.c are generated files. > Add this to gdbarch.sh instead, and regenerate them. Also it needs > documentation, as Eli said. OK, the attached patch has a modified gdbarch.sh and regenerated gdbarch.[ch]. I've also put a description into gdbint.texinfo > It would be nice if there were routines in dwarf2cfi.[ch] for creating > FDEs instead of having hex in the tdep file but that doesn't really > bother me. We can do that later when I need real FDEs. Yes, that could be taken from GCC I believe. But it can wait a little longer I belive... >>OK to commit to branch and mainline? > > I do not believe this is appropriate for the branch, at least until > it's sat on mainline without causing problems for some time. It shouldn't cause any problems because all the machinery is invoked if and only if the target allowed it, and then if a FDE isn't found for a particular function. Typically only two or three times on x86-64 and zero times on other archs. Can I put it at least to mainline? Michal Ludvig -- * SuSE CR, s.r.o * mludvig@suse.cz * (+420) 296.545.373 * http://www.suse.cz