SEGV on display /i $pc with i386 target

SEGV on display /i $pc with i386 target

[Christopher Faylor]

I just noticed a SEGV whenever I do a 'display /i $pc' on cygwin.

I tried building a gdb for linux to see what was going wrong on
cygwin but it isn't much better:

(top-gdb) display /i $pc
1: x/i $(null)  0x8072f42 <main+6>:     push   $0x6

The problem comes from the fact that, while gdb understands that
$pc == $eip, it doesn't seem to know how to rename $pc to $eip
when it is outputting the register name.  You can get the same
behavior by doing something like 'display /i $ps', too (even
if that doesn't make sense it shouldn't SEGV).

The simplest way to fix this is to extend the i386_register_names array
to include builtin register names, however, maybe the right way to fix
this is to add something to builtin-reg.c.

I noticed that i386_register_names seems to have 41 elements while
the sum of NUM_REGS + NUM_PSEUDO_REGS == 40.  Is that intentional?

cgf

Re: SEGV on display /i $pc with i386 target

[Mark Kettenis]

Christopher Faylor <cgf@redhat.com> writes:

> I just noticed a SEGV whenever I do a 'display /i $pc' on cygwin.
> 
> I tried building a gdb for linux to see what was going wrong on
> cygwin but it isn't much better:
> 
> (top-gdb) display /i $pc
> 1: x/i $(null)  0x8072f42 <main+6>:     push   $0x6
> 
> The problem comes from the fact that, while gdb understands that
> $pc == $eip, it doesn't seem to know how to rename $pc to $eip
> when it is outputting the register name.  You can get the same
> behavior by doing something like 'display /i $ps', too (even
> if that doesn't make sense it shouldn't SEGV).

Hmm, this defenitely used to work in the past.  Does anybody have an
idea what broke it?

> The simplest way to fix this is to extend the i386_register_names array
> to include builtin register names, however, maybe the right way to fix
> this is to add something to builtin-reg.c.

I suspect this problem isn't i386-specific, so extending
i386_register_names seems to be the wrong approach to me.

> I noticed that i386_register_names seems to have 41 elements while
> the sum of NUM_REGS + NUM_PSEUDO_REGS == 40.  Is that intentional?

Sort of.  In the current situation, Depending on whether your target
supports the SSE registers NUM_REGS will be either 32 or 41.  Since
NUM_PSEUDO_REGS is 6, and 32 + 6 = 40.

Perhaps this is a good moment to warn you about an implication of
multi-arching the i386 for Cygwin: the Cygwin targets don't support
SSE anymor, since we use the "Unknown" OS/ABI for Cygwin right now.  I
doubt whether this is what you want.  You probably want to introduce
some sort of Cygwin or Win32 OS/ABI that includes those registers.

Mark

Re: SEGV on display /i $pc with i386 target

[Christopher Faylor]

On Fri, Aug 30, 2002 at 12:40:10AM +0200, Mark Kettenis wrote:
>Christopher Faylor <cgf@redhat.com> writes:
>>I just noticed a SEGV whenever I do a 'display /i $pc' on cygwin.
>>
>>I tried building a gdb for linux to see what was going wrong on cygwin
>>but it isn't much better:
>>
>>(top-gdb) display /i $pc
>>1: x/i $(null)  0x8072f42 <main+6>:     push   $0x6
>>
>>The problem comes from the fact that, while gdb understands that $pc ==
>>$eip, it doesn't seem to know how to rename $pc to $eip when it is
>>outputting the register name.  You can get the same behavior by doing
>>something like 'display /i $ps', too (even if that doesn't make sense
>>it shouldn't SEGV).
>
>Hmm, this defenitely used to work in the past.  Does anybody have an
>idea what broke it?

I tested cygwin releases that I generated all the way back to April and
saw that, while there were no SEGVs on cygwin, I was getting bogus
output where I saw something like $xmmi used rather than $eib in the
display.

Maybe Andrew's 2002-08-13 change to i386_register_name may have stopped
that from occuring and, essentially, stopped masking some broken
behavior.

>>The simplest way to fix this is to extend the i386_register_names array
>>to include builtin register names, however, maybe the right way to fix
>>this is to add something to builtin-reg.c.
>
>I suspect this problem isn't i386-specific, so extending
>i386_register_names seems to be the wrong approach to me.

I agree.

>> I noticed that i386_register_names seems to have 41 elements while
>> the sum of NUM_REGS + NUM_PSEUDO_REGS == 40.  Is that intentional?
>
>Sort of.  In the current situation, Depending on whether your target
>supports the SSE registers NUM_REGS will be either 32 or 41.  Since
>NUM_PSEUDO_REGS is 6, and 32 + 6 = 40.
>
>Perhaps this is a good moment to warn you about an implication of
>multi-arching the i386 for Cygwin: the Cygwin targets don't support
>SSE anymor, since we use the "Unknown" OS/ABI for Cygwin right now.  I
>doubt whether this is what you want.  You probably want to introduce
>some sort of Cygwin or Win32 OS/ABI that includes those registers.

I noticed that while I was poking at this.  I'll put this on my
long todo list.

cgf

Re: SEGV on display /i $pc with i386 target

[Elena Zannoni]

Christopher Faylor writes:
 > On Fri, Aug 30, 2002 at 12:40:10AM +0200, Mark Kettenis wrote:
 > >Christopher Faylor <cgf@redhat.com> writes:
 > >>I just noticed a SEGV whenever I do a 'display /i $pc' on cygwin.
 > >>
 > >>I tried building a gdb for linux to see what was going wrong on cygwin
 > >>but it isn't much better:
 > >>
 > >>(top-gdb) display /i $pc
 > >>1: x/i $(null)  0x8072f42 <main+6>:     push   $0x6
 > >>
 > >>The problem comes from the fact that, while gdb understands that $pc ==
 > >>$eip, it doesn't seem to know how to rename $pc to $eip when it is
 > >>outputting the register name.  You can get the same behavior by doing
 > >>something like 'display /i $ps', too (even if that doesn't make sense
 > >>it shouldn't SEGV).
 > >
 > >Hmm, this defenitely used to work in the past.  Does anybody have an
 > >idea what broke it?
 > 
 > I tested cygwin releases that I generated all the way back to April and
 > saw that, while there were no SEGVs on cygwin, I was getting bogus
 > output where I saw something like $xmmi used rather than $eib in the
 > display.
 > 
 > Maybe Andrew's 2002-08-13 change to i386_register_name may have stopped
 > that from occuring and, essentially, stopped masking some broken
 > behavior.
 > 
 > >>The simplest way to fix this is to extend the i386_register_names array
 > >>to include builtin register names, however, maybe the right way to fix
 > >>this is to add something to builtin-reg.c.
 > >
 > >I suspect this problem isn't i386-specific, so extending
 > >i386_register_names seems to be the wrong approach to me.
 > 
 > I agree.

Seems like target_map_name_to_register is the problem?

Something to do with register aliases was changed between
1.17 and 1.18 versions of parse.c and between 1.21 and 1.22.

(a shot in the dark)
Elena


 > 
 > >> I noticed that i386_register_names seems to have 41 elements while
 > >> the sum of NUM_REGS + NUM_PSEUDO_REGS == 40.  Is that intentional?
 > >
 > >Sort of.  In the current situation, Depending on whether your target
 > >supports the SSE registers NUM_REGS will be either 32 or 41.  Since
 > >NUM_PSEUDO_REGS is 6, and 32 + 6 = 40.
 > >
 > >Perhaps this is a good moment to warn you about an implication of
 > >multi-arching the i386 for Cygwin: the Cygwin targets don't support
 > >SSE anymor, since we use the "Unknown" OS/ABI for Cygwin right now.  I
 > >doubt whether this is what you want.  You probably want to introduce
 > >some sort of Cygwin or Win32 OS/ABI that includes those registers.
 > 
 > I noticed that while I was poking at this.  I'll put this on my
 > long todo list.
 > 
 > cgf

Re: SEGV on display /i $pc with i386 target

[Christopher Faylor]

On Thu, Aug 29, 2002 at 11:35:43PM -0400, Elena Zannoni wrote:
>Seems like target_map_name_to_register is the problem?

It seems to be getting the correct correspondence between (in this
case) $eip and $pc.  You can see this by typing "print /x $pc"
"print /x $eip".  Both translate to the same thing.

It's only when the name itself needs to be displayed that it seems
to fall down.

cgf

Re: SEGV on display /i $pc with i386 target

[Andrew Cagney]

> On Thu, Aug 29, 2002 at 11:35:43PM -0400, Elena Zannoni wrote:
> 
>>Seems like target_map_name_to_register is the problem?

Yes.  It will be related to that.  When updating the code, I searched 
for something that relied on the reverse lookup (regnum -> name) but 
couldn't find anything (at least nothing that affected the testsuite).

> It seems to be getting the correct correspondence between (in this
> case) $eip and $pc.  You can see this by typing "print /x $pc"
> "print /x $eip".  Both translate to the same thing.
> 
> It's only when the name itself needs to be displayed that it seems
> to fall down.

GDB is mapping:

	"$pc" -> NUM_REGS+NUM_PSEUDO_REGS+<builtin-pc>

and then failing:

	... -> "$pc"

because the mechanism isn't there.

I'll figure out a patch.

	Andrew