This is the mail archive of the 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: [PATCH 0/3] Support for x86 segments as address classes

On 11/05/2015 12:21 PM, Pedro Alves wrote:
On 11/03/2015 01:43 PM, Richard Henderson wrote:
Which begs the question of whether I've simply missed
something in how to get hold of the current regcache?

get_current_frame / get_current_regcache ?  If you can pass it down
through a couple layers, it's of course better.

Duh, get_current_regcache, of course.  Thanks.

Which makes for a relatively easy patch to finish the support.

However, IMO the results aren't ideal.  Consider:

int test(void)
  int __seg_fs *f = (int __seg_fs *)16;
  int __seg_gs *g = (int __seg_gs *)16;
  return *f + *g;

int main()
  return 0;

Now, this really isn't a proper executable testcase, because I haven't set up gs_base, but since set up fs_base for the thread pointer, it's good enough to step into test() and examine some variables.

Breakpoint 2, test () at z.c:10
10	  return *f + *g;
(gdb) ptype f
type = int * @__seg_fs
(gdb) ptype g
type = int * @__seg_gs
(gdb) info loc
f = 0x7ffff7fd9710
g = 0x10

It seems to me that the "real" value of both f and g are 0x10. Instead, we display the converted value, displaying f with a surprising value.

It seems to me that it would be better to do the conversion when we want to dereference, such as "print *f", but not otherwise. However, I'm not really sure how that would interact with the other users of address classes throughout gdb.


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