This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: Simple exception use-case


Phil Muldoon wrote:
Ok if I break main, then run, and then finally add the catch throw and catch catch, it works. That's another on my list to investigate. But while doing this I stumbled onto something interesting. If you look at these two test-runs, one from upstream GDB one from a patched Fedora GDB you'll see that the Fedora GDB did not loose control of the inferior. This test is by no means conclusive, but it intrigues me. For the purpose of this use-case and estimation I was going to concentrate purely on upstream, but I think I'll take a look at Fedora GDB and investigate the patch load. There may be a patch that already fixes possible longjmp or other inferior control issues. If so, can look at the estimation to convert this patch upstream, tweak it - whatever - over writing new support. At the very least I'll investigate why this one use-cases diverges on two different GDBs.
Replying to myself. If I build the Fedora RPM without any patches at all, the behaviour is the same (ie stepping when in the libstdc++ code does not lose control of the inferior). The only difference in the Fedora build, and my build from upstream CVS is that Fedora GDB has a configure option (among others):

--with-separate-debug-dir=/usr/lib/debug

If I build upstream gdb-6.8 with that option, GDB does not lose control of the inferior when stepping through the catch libstdc++ code. If I build without that option, stepping after a: "catch catch" and control is lost. Oh well, it was worth a morning investigating it. I certainly learnt a lot ;) But this is a separate (debuginfo) issue I think (?)

Regards

Phil


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