This is the mail archive of the gdb@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: SIG32/SIGTRAP issues


On Tue, Dec 03, 2002 at 06:58:33PM -0500, Daniel Jacobowitz wrote:
> On Tue, Dec 03, 2002 at 06:52:30PM -0500, Andrew Cagney wrote:
> > >
> > >Funny, no one reports this for months and this is the third report I've
> > >seen in a week...  At the bottom of this message is a workaround.  I'm
> > >not proposing it be committed, since it's obviously pretty gross.  The
> > >real issue is the concept of thread_stratum and core_stratum as
> > >separate from process_stratum.  I don't think it's appropriate - if we
> > >are debugging a core and process at the same time this isn't how it
> > >should work.  This ties in to all the make-targets-a-real-stack thing -
> > >I'm not entirely convinced on that score either.
> > 
> > GDB Speak :-)  `An inferior stack', separate to the stratum.  Having 
> > implemented the idea, I'm pretty much convinced it's the correct 
> > approach (although, as you demonstrate, not absolutly necessary).
> 
> Hrm, interesting.  A stack doesn't seem logical for that, just support
> for multiple targets... pull one out when you want it.  That could be
> adapted to solve this problem.  Let's see the code :)
> 
> 
> ===
> 
> 
> HJ, I'm pretty sure your patch won't work right in this case:
> 
> # gdb static-app corefile
> (gdb) run
> 
> There will be no new call to the objfile hook, and no new pushes, and
> thread-db won't load.
> 

No, it is not perfect.


H.J.


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