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: [RFA] Remove calls to inside_entry_file



> Per my previous comment, I'd prefer to not touch the old code at all - > let it die. Mark, I'll note, already has i386 replacement code in waiting.
> > The other thing to do is to ask DanielJ if he knows anything more about > that specific case.


Nope. It was there before I put my hands on it; it seems suspicious to me though.


What do you mean by "suspicious"?  You did already comment on this in
blockframe.c so I assume you had rather mixed feelings about this call.

I don't see a reason not to change this.  It will take some time to
move all targets to the new scheme.  Why should some of the not converted
targets remain broken due to an obvious bug?

I'm beginning to think that reverting some of the original change:


RFC: Mostly kill FRAME_CHAIN_VALID, add user knob
http://sources.redhat.com/ml/gdb-patches/2002-12/msg00683.html

might be the best option. What about moving this:

> +
> + /* If the architecture has a custom FRAME_CHAIN_VALID, call it now. */
> + if (FRAME_CHAIN_VALID_P ())
> + return FRAME_CHAIN_VALID (fp, fi);


to before this:

+ /* If we're already inside the entry function for the main objfile, then it
+ isn't valid. */
+ if (inside_entry_func (get_frame_pc (fi)))
+ return 0;
+
+ /* If we're inside the entry file, it isn't valid. */
+ /* NOTE/drow 2002-12-25: should there be a way to disable this check? It
+ assumes a single small entry file, and the way some debug readers (e.g.
+ dbxread) figure out which object is the entry file is somewhat hokey. */
+ if (inside_entry_file (frame_pc_unwind (fi)))
+ return 0;
+
+ /* If we want backtraces to stop at main, and we're inside main, then it
+ isn't valid. */
+ if (!backtrace_below_main && inside_main_func (get_frame_pc (fi)))
+ return 0;


That more closely resembles the original behavior.

Andrew



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