public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* Re: tdep/2305: IA64: breakpoints on predicated instructions ignore predicate
@ 2007-08-29 18:08 John S. Worley
0 siblings, 0 replies; 6+ messages in thread
From: John S. Worley @ 2007-08-29 18:08 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR tdep/2305; it has been noted by GNATS.
From: "John S. Worley" <jsworley@qwest.net>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: tdep/2305: IA64: breakpoints on predicated instructions ignore
predicate
Date: Wed, 29 Aug 2007 11:58:41 -0600
This is a cryptographically signed message in MIME format.
--------------ms010801090506010403050404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel -
Thanks for the reply. I don't agree that using conditional
breakpoints is equivalent,
at least from a performance standpoint. If it takes hours to encounter
the boundary or
error condition, breaking every time through the loop, even when GDB
continues,
will increase that by several orders of magnitude, especially in a
remote debugging situation,
where the cost of taking a breakpoint is magnified many times.
In terms of "generally expected" behavior, I don't agree with your
example: in this case,
you can and should set the breakpoint on the instruction with computes
the 'a == b'
predicate. I'm willing to accept that there may be some obscure scenario
where honoring
the predicate is incorrect, but I can't think of any. As a counter
example, consider the code
that brought this issue to my attention:
if (ptr != NULL) {
*ptr = 0;
}
which any reasonable compiler would optimize as:
cmp.ne pX, pY = r0, rPTR ;;
(pX) st4 [ rPTR ] = r0
in parallel with other independent instructions. Setting a
breakpoint at the assignment statement
in GDB will break every time through the code, even when ptr == NULL,
which is certainly *NOT
*the expected (or reasonable) behavior. It is also unreasonable to
require the programmer, who may
not be IA64 savvy, to have to disassemble the code to see if the
instruction replaced is predicated.
As IA64 compilers, both GNU and non-GNU, improve, there are going to
be more and
more conditions like this one. It is already the case for hand assembly,
where multiple complex
computations, each with it's own predicate(s), can be woven together in
parallel. Just placing
an unqualified break instruction is not correct behavior now, and will
only become increasingly
incorrect in the future.
Regards,
John Worley
jsworley@qwest.net
--------------ms010801090506010403050404
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQFjCC
BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l
dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN
NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy
lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq
vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6
hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu
9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G
A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU
cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk
ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi
54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0
g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd
WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz
Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy
XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFwDCCBKigAwIBAgIQKuzMLqPOTPUh
9i5Ni2ASHTANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw
FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr
MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS
Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0wNzA3MDMwMDAwMDBa
Fw0wODA3MDIyMzU5NTlaMIHZMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF
UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2Yg
dXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAw
MyBDb21vZG8gTGltaXRlZDEUMBIGA1UEAxMLSm9obiBXb3JsZXkxITAfBgkqhkiG9w0BCQEW
Empzd29ybGV5QHF3ZXN0Lm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvWXuFM8r
wIoO3wGGX++zUoORO6vBjPmti6kLKMq1e0/pQgZAi+fnfzxuoE0M+3/2+33WZa0lcAehJ7rP
eW4zrq/3DA1eFQums1tsNNeeGuJgXHWKS2jWYEP8AiX8BO/vQ31B7QybOfned0YAvSkYwpYF
9vYWPS1gFHZOOPPZ5IkCAwEAAaOCAi8wggIrMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh8
3j2uBG59MB0GA1UdDgQWBBTwGHaIvlVptpOx8DA+XbwoUUbwUDAOBgNVHQ8BAf8EBAMCBaAw
DAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI
AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW
HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0
dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRp
b25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZp
cnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMIGGBggrBgEFBQcBAQR6MHgw
OwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL1VUTkFkZFRydXN0Q2xpZW50
Q0EuY3J0MDkGCCsGAQUFBzAChi1odHRwOi8vY3J0LmNvbW9kby5uZXQvVVROQWRkVHJ1c3RD
bGllbnRDQS5jcnQwHQYDVR0RBBYwFIESanN3b3JsZXlAcXdlc3QubmV0MA0GCSqGSIb3DQEB
BQUAA4IBAQABY1YWJG7rfXnH5lXsYmAwSnnnm5zNtiGeLw31rQRTO1GctyOM2NJyA9WoXwvA
RLt5lz25BsjDwciJ7x9Hp8BK1tUd2Q8Xay39JxYeqHsCX9EPLowsI1k8vap9F6UaAFD8Mgbz
b5OhIecWLqOseDt9qnURNco4SnI4XUby+Z2iZjPCl/UF7mBjAUaQYAfsKVbUOWZxV+AII2m5
h2A2TpFSAin9W8bWs3Ro8vqrjFPnNGZwp1oM9DJAlvfrCIDNGr5CWfMpZbBxMfFV/s2h/etk
NvnrQbyDw/Gbg2XAEYJUxWj98DNBQoaCJBpvCOV8hImTzMkSRbGy7FmcblYBFt1JMIIFwDCC
BKigAwIBAgIQKuzMLqPOTPUh9i5Ni2ASHTANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl
IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20x
NjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFp
bDAeFw0wNzA3MDMwMDAwMDBaFw0wODA3MDIyMzU5NTlaMIHZMTUwMwYDVQQLEyxDb21vZG8g
VHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMg
YW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9y
eTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEUMBIGA1UEAxMLSm9obiBXb3Js
ZXkxITAfBgkqhkiG9w0BCQEWEmpzd29ybGV5QHF3ZXN0Lm5ldDCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAvWXuFM8rwIoO3wGGX++zUoORO6vBjPmti6kLKMq1e0/pQgZAi+fnfzxu
oE0M+3/2+33WZa0lcAehJ7rPeW4zrq/3DA1eFQums1tsNNeeGuJgXHWKS2jWYEP8AiX8BO/v
Q31B7QybOfned0YAvSkYwpYF9vYWPS1gFHZOOPPZ5IkCAwEAAaOCAi8wggIrMB8GA1UdIwQY
MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBTwGHaIvlVptpOx8DA+XbwoUUbw
UDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL
KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC
AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV
HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt
Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t
b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js
MIGGBggrBgEFBQcBAQR6MHgwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29t
L1VUTkFkZFRydXN0Q2xpZW50Q0EuY3J0MDkGCCsGAQUFBzAChi1odHRwOi8vY3J0LmNvbW9k
by5uZXQvVVROQWRkVHJ1c3RDbGllbnRDQS5jcnQwHQYDVR0RBBYwFIESanN3b3JsZXlAcXdl
c3QubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQABY1YWJG7rfXnH5lXsYmAwSnnnm5zNtiGeLw31
rQRTO1GctyOM2NJyA9WoXwvARLt5lz25BsjDwciJ7x9Hp8BK1tUd2Q8Xay39JxYeqHsCX9EP
LowsI1k8vap9F6UaAFD8Mgbzb5OhIecWLqOseDt9qnURNco4SnI4XUby+Z2iZjPCl/UF7mBj
AUaQYAfsKVbUOWZxV+AII2m5h2A2TpFSAin9W8bWs3Ro8vqrjFPnNGZwp1oM9DJAlvfrCIDN
Gr5CWfMpZbBxMfFV/s2h/etkNvnrQbyDw/Gbg2XAEYJUxWj98DNBQoaCJBpvCOV8hImTzMkS
RbGy7FmcblYBFt1JMYIDzzCCA8sCAQEwgcMwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV
VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0
d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t
VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCECrszC6jzkz1IfYu
TYtgEh0wCQYFKw4DAhoFAKCCAmEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDcwODI5MTc1ODQxWjAjBgkqhkiG9w0BCQQxFgQUDR3SGTm2vdq5urZRMdJz
EvsfJm0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdQGCSsGAQQBgjcQBDGBxjCB
wzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0
eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3
LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp
Y2F0aW9uIGFuZCBFbWFpbAIQKuzMLqPOTPUh9i5Ni2ASHTCB1gYLKoZIhvcNAQkQAgsxgcag
gcMwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp
dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3
dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgRW1haWwCECrszC6jzkz1IfYuTYtgEh0wDQYJKoZIhvcNAQEBBQAEgYAW
rn7U4udg6SXEP6eeDKaLST7YQOHMG7zMDjEcR8FhSCely0Z8B8HB+K7xoFYybDps1HBicnJD
44PdFBiBKtf0u/5WbjbCpfNnVRHaE9/enO0wVigy1dFwFsQpdJ6YyVL1dUsEJtFYRwDxCSBc
vdRuuqV/4RhMRRuyFc+1Esh6qwAAAAAAAA==
--------------ms010801090506010403050404--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tdep/2305: IA64: breakpoints on predicated instructions ignore predicate
@ 2007-08-29 21:18 Daniel Jacobowitz
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2007-08-29 21:18 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR tdep/2305; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@false.org>
To: "John S. Worley" <jsworley@qwest.net>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: tdep/2305: IA64: breakpoints on predicated instructions ignore
predicate
Date: Wed, 29 Aug 2007 17:10:04 -0400
On Wed, Aug 29, 2007 at 02:59:37PM -0600, John S. Worley wrote:
> > Stopping on line 91 (i.e., arbitrarily far earlier) is unacceptable.
> >
> Why?
Because if you do this, most of your breakpoints are going to end up
at a load of 0 into a register at the very beginning of your function.
GDB has to do the best it can with optimized code. This relies on
both GDB and GCC making intelligent decisions about what is
"interesting". Jim Blandy had some proposals to do this in more
depth, focusing on expressions with user-visible side effects
(like the stores to z and a). I don't know if they'll ever come
to be.
> With a breakpoint set at 112, is completely unexpected, confusing,
> time-consuming, and just plain wrong.
I didn't say that it was right. I said that changing this wrong
behavior for the other wrong behavior was much worse.
> > It has very little to do with IA-64 and we have discussed it before in
> > ARM and other contexts.
> >
> It has a lot to do with IA64, since it's parallelism and rich predication
> calculus are changing the
> rules and challenging conventional wisdoms about assembly programming and
> compilation.
I am heartily sick of hearing about how new, unique, and original IA64
is. Predication, _and the problems of debugging it_, are not new and
have been discussed before.
> > I'm not interested in trading unexpected stops for unexpected failures
> > to stop. Experience has definitely shown that when we can't get it
> > right, stopping more often is better than less often.
> >
> >
> Stopping more often is not a better choice, just a simpler one.
Disagree based on six years of GDB maintenance.
> I suggest
> there is a need for both
> types of breakpoints, at a minimum because single stepping at the instruction
> level requires it. I would
> accept the argument that the false stop problem may require action on the
> user's part, such as a
> IA64-only command like 'breaki' to insert breakpoints that honor the predicate.
> Is there a guide for
> adding architecture-dependent commands to GDB?
No. It probably shouldn't be architecture-dependent, though. Again,
this is not unique to IA-64.
You may wish to take this discussion to the GDB mailing list, as it
requires some amount of design to figure out what would be useful and
whether we have better, automatic solutions available.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tdep/2305: IA64: breakpoints on predicated instructions ignore predicate
@ 2007-08-29 21:08 John S. Worley
0 siblings, 0 replies; 6+ messages in thread
From: John S. Worley @ 2007-08-29 21:08 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR tdep/2305; it has been noted by GNATS.
From: "John S. Worley" <jsworley@qwest.net>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: tdep/2305: IA64: breakpoints on predicated instructions ignore
predicate
Date: Wed, 29 Aug 2007 14:59:37 -0600
This is a cryptographically signed message in MIME format.
--------------ms040806050007080101030606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel -
> Consider:
>
> 91 z = b ? x : y;
> 92 a = b ? c : d;
>
> Optimized to set a predicate in line 91, and then four conditional
> moves (probably in only two bundles).
>
> The user clicks on line 92 in their IDE. GDB should stop on line 92.
> Stopping on line 91 (i.e., arbitrarily far earlier) is unacceptable.
>
Why? It is well known that optimizers blur the boundaries between
lines of code, especially in
a highly parallel machine like IA64. The fact of your example is that
the compiler has recognized
and eliminated a common subexpression. Consider a variant of your example:
15 int
16 aaa(int b)
17 {
18 int a, z;
19
20 a = b;
21 z = a ? 24 : 15;
22 a = a ? -4 : -8;
23
24 return (a + z + b);
25 }
Now, the optimizer does a great job with this - it recognizes that
it can select a constant value to
add to 'b' for the return value. In effect, all the assignments have
been eliminated. Now, if the user
sets the breakpoint at line 20, which doesn't really exist, it points to
the same arbitrary instruction as
line 21, e.g., setting a predicate based on b. In effect, the user can
set the breakpoint at 20 or 21, but
not both, and 'step' will skip one line or the other.
Setting a breakpoint at 22 hits the instruction that picks the
constant '7' (15 - 8), which is another
arbitrary choice, since the next instruction (constant '20') is just a
much a part of line 22 (or 20 or 21)
as the previous, e.g., it isn't.
The point here is that stopping at an instruction that "belongs" to
line 91 AND 92 (in your example)
is no more egregious that stopping at an instruction that has no
correlation to the 'C' code whatever.
It's just one of the hard problems of debugging optimized code.
However, to make the choice to stop at code that isn't being
logically executed , e.g:
107 if (a < 0) {
108 b = 14 - a;
109 } else if (a > 0) {
110 b = a - 54;
111 } else {
112 b = 11;
113 }
With a breakpoint set at 112, is completely unexpected, confusing,
time-consuming, and just plain wrong.
> It has very little to do with IA-64 and we have discussed it before in
> ARM and other contexts.
>
It has a lot to do with IA64, since it's parallelism and rich
predication calculus are changing the
rules and challenging conventional wisdoms about assembly programming
and compilation. The notion
that, to paraphrase Stein, "instruction is an instruction is an
instruction is an instruction", is untenable.
> I'm not interested in trading unexpected stops for unexpected failures
> to stop. Experience has definitely shown that when we can't get it
> right, stopping more often is better than less often.
>
>
Stopping more often is not a better choice, just a simpler one. I
suggest there is a need for both
types of breakpoints, at a minimum because single stepping at the
instruction level requires it. I would
accept the argument that the false stop problem may require action on
the user's part, such as a
IA64-only command like 'breaki' to insert breakpoints that honor the
predicate. Is there a guide for
adding architecture-dependent commands to GDB?
Regards,
John Worley
jsworley@qwest.net
--------------ms040806050007080101030606
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQFjCC
BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l
dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN
NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy
lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq
vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6
hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu
9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G
A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU
cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk
ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi
54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0
g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd
WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz
Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy
XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFwDCCBKigAwIBAgIQKuzMLqPOTPUh
9i5Ni2ASHTANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw
FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr
MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS
Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0wNzA3MDMwMDAwMDBa
Fw0wODA3MDIyMzU5NTlaMIHZMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF
UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2Yg
dXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAw
MyBDb21vZG8gTGltaXRlZDEUMBIGA1UEAxMLSm9obiBXb3JsZXkxITAfBgkqhkiG9w0BCQEW
Empzd29ybGV5QHF3ZXN0Lm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvWXuFM8r
wIoO3wGGX++zUoORO6vBjPmti6kLKMq1e0/pQgZAi+fnfzxuoE0M+3/2+33WZa0lcAehJ7rP
eW4zrq/3DA1eFQums1tsNNeeGuJgXHWKS2jWYEP8AiX8BO/vQ31B7QybOfned0YAvSkYwpYF
9vYWPS1gFHZOOPPZ5IkCAwEAAaOCAi8wggIrMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh8
3j2uBG59MB0GA1UdDgQWBBTwGHaIvlVptpOx8DA+XbwoUUbwUDAOBgNVHQ8BAf8EBAMCBaAw
DAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI
AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW
HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0
dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRp
b25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZp
cnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMIGGBggrBgEFBQcBAQR6MHgw
OwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL1VUTkFkZFRydXN0Q2xpZW50
Q0EuY3J0MDkGCCsGAQUFBzAChi1odHRwOi8vY3J0LmNvbW9kby5uZXQvVVROQWRkVHJ1c3RD
bGllbnRDQS5jcnQwHQYDVR0RBBYwFIESanN3b3JsZXlAcXdlc3QubmV0MA0GCSqGSIb3DQEB
BQUAA4IBAQABY1YWJG7rfXnH5lXsYmAwSnnnm5zNtiGeLw31rQRTO1GctyOM2NJyA9WoXwvA
RLt5lz25BsjDwciJ7x9Hp8BK1tUd2Q8Xay39JxYeqHsCX9EPLowsI1k8vap9F6UaAFD8Mgbz
b5OhIecWLqOseDt9qnURNco4SnI4XUby+Z2iZjPCl/UF7mBjAUaQYAfsKVbUOWZxV+AII2m5
h2A2TpFSAin9W8bWs3Ro8vqrjFPnNGZwp1oM9DJAlvfrCIDNGr5CWfMpZbBxMfFV/s2h/etk
NvnrQbyDw/Gbg2XAEYJUxWj98DNBQoaCJBpvCOV8hImTzMkSRbGy7FmcblYBFt1JMIIFwDCC
BKigAwIBAgIQKuzMLqPOTPUh9i5Ni2ASHTANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl
IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20x
NjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFp
bDAeFw0wNzA3MDMwMDAwMDBaFw0wODA3MDIyMzU5NTlaMIHZMTUwMwYDVQQLEyxDb21vZG8g
VHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMg
YW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9y
eTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEUMBIGA1UEAxMLSm9obiBXb3Js
ZXkxITAfBgkqhkiG9w0BCQEWEmpzd29ybGV5QHF3ZXN0Lm5ldDCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAvWXuFM8rwIoO3wGGX++zUoORO6vBjPmti6kLKMq1e0/pQgZAi+fnfzxu
oE0M+3/2+33WZa0lcAehJ7rPeW4zrq/3DA1eFQums1tsNNeeGuJgXHWKS2jWYEP8AiX8BO/v
Q31B7QybOfned0YAvSkYwpYF9vYWPS1gFHZOOPPZ5IkCAwEAAaOCAi8wggIrMB8GA1UdIwQY
MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBTwGHaIvlVptpOx8DA+XbwoUUbw
UDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL
KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC
AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV
HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt
Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t
b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js
MIGGBggrBgEFBQcBAQR6MHgwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29t
L1VUTkFkZFRydXN0Q2xpZW50Q0EuY3J0MDkGCCsGAQUFBzAChi1odHRwOi8vY3J0LmNvbW9k
by5uZXQvVVROQWRkVHJ1c3RDbGllbnRDQS5jcnQwHQYDVR0RBBYwFIESanN3b3JsZXlAcXdl
c3QubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQABY1YWJG7rfXnH5lXsYmAwSnnnm5zNtiGeLw31
rQRTO1GctyOM2NJyA9WoXwvARLt5lz25BsjDwciJ7x9Hp8BK1tUd2Q8Xay39JxYeqHsCX9EP
LowsI1k8vap9F6UaAFD8Mgbzb5OhIecWLqOseDt9qnURNco4SnI4XUby+Z2iZjPCl/UF7mBj
AUaQYAfsKVbUOWZxV+AII2m5h2A2TpFSAin9W8bWs3Ro8vqrjFPnNGZwp1oM9DJAlvfrCIDN
Gr5CWfMpZbBxMfFV/s2h/etkNvnrQbyDw/Gbg2XAEYJUxWj98DNBQoaCJBpvCOV8hImTzMkS
RbGy7FmcblYBFt1JMYIDzzCCA8sCAQEwgcMwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV
VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0
d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t
VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCECrszC6jzkz1IfYu
TYtgEh0wCQYFKw4DAhoFAKCCAmEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDcwODI5MjA1OTM3WjAjBgkqhkiG9w0BCQQxFgQUac1Wa4s7uziAUF3bz6WO
qslah18wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdQGCSsGAQQBgjcQBDGBxjCB
wzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0
eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3
LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp
Y2F0aW9uIGFuZCBFbWFpbAIQKuzMLqPOTPUh9i5Ni2ASHTCB1gYLKoZIhvcNAQkQAgsxgcag
gcMwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp
dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3
dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgRW1haWwCECrszC6jzkz1IfYuTYtgEh0wDQYJKoZIhvcNAQEBBQAEgYBy
9rKtuVKfmjCCQMYKtw1cVpd5r0qcdZz0b9T/SQtkeyc/45OmNKKp7WbvIG0Xg+N+PAh8FxHg
wykVKiH00gl8jw9sLD/e0bgHMCkJURVe6kMIxVCraDw5Crdk9YKekLMdrKmWo2UBm7DB42nq
ZZiEB/TN7C8eLQK05yVLTyPESAAAAAAAAA==
--------------ms040806050007080101030606--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tdep/2305: IA64: breakpoints on predicated instructions ignore predicate
@ 2007-08-29 18:28 Daniel Jacobowitz
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2007-08-29 18:28 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR tdep/2305; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@false.org>
To: "John S. Worley" <jsworley@qwest.net>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: tdep/2305: IA64: breakpoints on predicated instructions ignore
predicate
Date: Wed, 29 Aug 2007 14:27:17 -0400
On Wed, Aug 29, 2007 at 11:58:41AM -0600, John S. Worley wrote:
> Daniel -
>
> Thanks for the reply. I don't agree that using conditional breakpoints is
> equivalent,
I never said it was equivalent. It is the practical option.
It would also be possible to implement an optimization in GDB where it
uses conditional breakpoint instructions.
>
> In terms of "generally expected" behavior, I don't agree with your example:
> in this case,
> you can and should set the breakpoint on the instruction with computes the 'a
> == b'
> predicate.
No way. You're thinking from the perspective of a user who can look
at the generated instructions and draw some sensible conclusion.
Consider:
91 z = b ? x : y;
92 a = b ? c : d;
Optimized to set a predicate in line 91, and then four conditional
moves (probably in only two bundles).
The user clicks on line 92 in their IDE. GDB should stop on line 92.
Stopping on line 91 (i.e., arbitrarily far earlier) is unacceptable.
Stopping only when the predicate is true is also unacceptable.
> in parallel with other independent instructions. Setting a breakpoint at the
> assignment statement
> in GDB will break every time through the code, even when ptr == NULL, which is
> certainly *NOT
> *the expected (or reasonable) behavior.
Yes. This is one of the hard problems in debuggering optimized code.
It has very little to do with IA-64 and we have discussed it before in
ARM and other contexts.
Using a conditional breakpoint is only reasonable if the compiler
indicates in debug info that the line is predicated. No compiler that
I know of generates such information and doing so in an optimizing
compiler is quite hard.
I'm not interested in trading unexpected stops for unexpected failures
to stop. Experience has definitely shown that when we can't get it
right, stopping more often is better than less often.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tdep/2305: IA64: breakpoints on predicated instructions ignore predicate
@ 2007-08-29 17:08 Daniel Jacobowitz
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2007-08-29 17:08 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR tdep/2305; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@false.org>
To: jsworley@qwest.net
Cc: gdb-gnats@sources.redhat.com
Subject: Re: tdep/2305: IA64: breakpoints on predicated instructions ignore
predicate
Date: Wed, 29 Aug 2007 13:03:24 -0400
On Wed, Aug 29, 2007 at 04:41:41PM -0000, jsworley@qwest.net wrote:
> When setting a breakpoint at a predicated instruction, GDB sets the
> predicate to p0 (always). This makes it impossible to only catch the
> case where the predicate is set, such as for a boundary or error
> conditon. This situation can arise in assembly code or optimized
> compilation.
GDB's current behavior is the generally expected one. If you would
like to honor the predicate, you can set an appropriate conditional
breakpoint (with "condition" or "break if").
If we honor the predicate things go wrong in all sorts of different
ways. For a simple example, suppose the compiler optimizes "a = b ? c
: d" into two conditional moves and an appropriate predicate was
already in a register for b. Setting a breakpoint at that line will
end up on one of the conditional moves; if the other condition is
chosen then the breakpoint will be silently skipped (and we'll get
a different bug report about that :-)
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 6+ messages in thread
* tdep/2305: IA64: breakpoints on predicated instructions ignore predicate
@ 2007-08-29 16:48 jsworley
0 siblings, 0 replies; 6+ messages in thread
From: jsworley @ 2007-08-29 16:48 UTC (permalink / raw)
To: gdb-gnats
>Number: 2305
>Category: tdep
>Synopsis: IA64: breakpoints on predicated instructions ignore predicate
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Wed Aug 29 16:48:01 UTC 2007
>Closed-Date:
>Last-Modified:
>Originator: John Worley
>Release: 6.6
>Organization:
>Environment:
ia64-unknown-linux-gnu
>Description:
When setting a breakpoint at a predicated instruction, GDB sets the predicate to p0 (always). This makes it impossible to only catch the case where the predicate is set, such as for a boundary or error conditon. This situation can arise in assembly code or optimized compilation.
>How-To-Repeat:
Set a breakpoint at a predicated instruction; observe that the breakpoint is hit whether the predicate is set or not.
>Fix:
This can be simply fixed by copying the 6-bit predicate field from the replaced instruction into the break instruction. The following patch to ia64-tdep.c (6.6) does this and seems to work correctly. If there is a symbolic definition for the predicate field, please replace 0x3f as appropriate.
--- ia64-tdep.c 2007-08-29 10:11:30.844771725 -0600
+++ ia64-tdep.orig 2007-08-29 10:10:46.868275292 -0600
@@ -556,5 +556,5 @@
char bundle[BUNDLE_LEN];
int slotnum = (int) (addr & 0x0f) / SLOT_MULTIPLIER;
- long long instr, brk;
+ long long instr;
int val;
int template;
@@ -578,6 +578,5 @@
memcpy (bp_tgt->shadow_contents, &instr, sizeof (instr));
bp_tgt->placed_size = bp_tgt->shadow_len = sizeof (instr);
- brk = IA64_BREAKPOINT | (instr & 0x3f);
- replace_slotN_contents (bundle, brk, slotnum);
+ replace_slotN_contents (bundle, IA64_BREAKPOINT, slotnum);
if (val == 0)
target_write_memory (addr, bundle, BUNDLE_LEN);
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-08-29 21:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-08-29 18:08 tdep/2305: IA64: breakpoints on predicated instructions ignore predicate John S. Worley
-- strict thread matches above, loose matches on Subject: below --
2007-08-29 21:18 Daniel Jacobowitz
2007-08-29 21:08 John S. Worley
2007-08-29 18:28 Daniel Jacobowitz
2007-08-29 17:08 Daniel Jacobowitz
2007-08-29 16:48 jsworley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).