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: [offbyone RFC] Merge i386newframe

From: Andrew Cagney <ac131313 at redhat dot com>
To: Michal Ludvig <mludvig at suse dot cz>
Cc: Mark Kettenis <kettenis at chello dot nl>,GDB Patches <gdb-patches at sources dot redhat dot com>
Date: Fri, 14 Mar 2003 10:59:07 -0500
Subject: Re: [offbyone RFC] Merge i386newframe
References: <3E6FAF64.7070304@suse.cz> <3E70D673.1040504@redhat.com> <3E71C2F9.3060504@suse.cz>

I suspect Daniel's answered this. The frame ID needs to be constant through out the lifetime of the frame. Getting that right isn't trivial. However, getting it right can receive a bonus: d10v now passing mips_pro.exp.

You mean the whole ID should be constant or just id.base? If id.pc must be constant as well, it couldn't represent the PC register anymore... I'm confused.

At present, just the base needs to be constant.

However, to differentiate between two frameless functions, and to re-find a frameless function, both the frame base and the frame function's start address need to be compared. GDB doesn't yet do this and when it does, it may need to refine what that PC value is.

"frame.h" mentions the problem.

Andrew

References:
- [offbyone RFC] Merge i386newframe
  - From: Michal Ludvig
- Re: [offbyone RFC] Merge i386newframe
  - From: Andrew Cagney
- Re: [offbyone RFC] Merge i386newframe
  - From: Michal Ludvig

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