Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Richard Henderson <rth@redhat.com>
To: Pedro Alves <palves@redhat.com>, gdb-patches@gcc.gnu.org
Subject: Re: [PATCH 0/3] Support for x86 segments as address classes
Date: Thu, 05 Nov 2015 14:15:00 -0000	[thread overview]
Message-ID: <563B646D.7000805@redhat.com> (raw)
In-Reply-To: <563B3BA3.3070402@redhat.com>

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()
{
   test();
   return 0;
}

Now, this really isn't a proper executable testcase, because I haven't set up 
gs_base, but since libc.so 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.


r~


  reply	other threads:[~2015-11-05 14:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03 13:43 Richard Henderson
2015-11-03 13:43 ` [PATCH 2/3] Use register cache for x86_64 ps_get_thread_area Richard Henderson
2015-11-03 13:44 ` [PATCH 3/3] Segment support for x86_64, part 1 Richard Henderson
2015-11-03 13:44 ` [PATCH 1/3] Add amd64 registers fs_base and gs_base Richard Henderson
2015-11-05 11:21 ` [PATCH 0/3] Support for x86 segments as address classes Pedro Alves
2015-11-05 14:15   ` Richard Henderson [this message]
2015-11-18 18:18     ` Ulrich Weigand
2015-11-05 14:18 ` [PATCH 4/3] Segment support for x86_64, part 2 Richard Henderson
2015-11-27 14:34 ` [PATCH 0/3] Support for x86 segments as address classes Gary Benson
2016-04-19 14:23 ` Tedeschi, Walfred
2016-04-19 14:44   ` Richard Henderson
2016-04-19 14:47     ` Walfred Tedeschi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=563B646D.7000805@redhat.com \
    --to=rth@redhat.com \
    --cc=gdb-patches@gcc.gnu.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox