From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23252 invoked by alias); 27 Sep 2010 08:54:17 -0000 Received: (qmail 23243 invoked by uid 22791); 27 Sep 2010 08:54:16 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_00,TW_BF,TW_RB X-Spam-Check-By: sourceware.org Received: from mail-ey0-f169.google.com (HELO mail-ey0-f169.google.com) (209.85.215.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Sep 2010 08:54:11 +0000 Received: by eyh5 with SMTP id 5so1492934eyh.0 for ; Mon, 27 Sep 2010 01:54:07 -0700 (PDT) Received: by 10.213.33.84 with SMTP id g20mr2862317ebd.4.1285577647149; Mon, 27 Sep 2010 01:54:07 -0700 (PDT) Received: from [10.16.35.228] ([130.225.93.51]) by mx.google.com with ESMTPS id a48sm8124249eei.18.2010.09.27.01.54.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Sep 2010 01:54:06 -0700 (PDT) From: Niklas Quarfot Nielsen Content-Type: multipart/signed; boundary=Apple-Mail-2-180283207; protocol="application/pkcs7-signature"; micalg=sha1 Subject: GDB remote debugging stub: Question about memory read Date: Mon, 27 Sep 2010 08:54:00 -0000 Message-Id: <1257E26A-12FB-432E-A18C-137440C02080@qni.dk> To: gdb@sourceware.org Mime-Version: 1.0 (Apple Message framework v1081) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00145.txt.bz2 --Apple-Mail-2-180283207 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Content-length: 1717 Hi everyone, I just subscribed to this list, so if I do not follow your mailing list con= ventions - please let me know. I am implementing a remote debugging stub for a research operating system a= t the technical university of Denmark. GDB can connect and if I disable memory reads, single stepping and hardware= breakpointing works fine. So serial communication and initialization shou= ld be in order. The problem arises when GDB requests memory read of the stack (right after = the g-packet as been received). The registers contains the following: rax 0x0 rbx 0xb816a rcx 0x6e rdx 0x8 rsi 0xffff8000000b8000 rdi 0xb8000 rbp 0xffffffff6efffff0 rsp 0xffffffff6effffd0 r8 0x5 r9 0x78bfbff r10 0x0 r11 0x0 r12 0x0 r13 0x0 r14 0x0 r15 0x0 rip 0xffffffff80200293 eflags 0x46 [ PF ZF ] cs 0x18 ss 0x0 ds 0x0 es 0x0 fs 0x0 GDB tries to read 0x40 bytes starting at address 0xffffffff6effffc0, which = (I guess) is from the RSP. Packet: mffffffff6effffc0,40 My question is: Why does GDB try to read 0x40 bytes, when there is only 0x20 bytes on the s= tack (RBP-RSP)? The architecture is an AMD64 and the version of GDB is 7.1(x86_64-gnu-linux= ). I appreciate any answer and/or clue to why GDB behaves like this. I have tried to look through the remote debugging source code of GDB, but t= his has not given me any answers. If needed, I can post debugging information from the target code in GDB. Best regards Niklas Quarfot Nielsen --Apple-Mail-2-180283207 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-length: 2611 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIFcjCCBW4wggRWoAMCAQICBEWJ3qEwDQYJKoZIhvcNAQEFBQAwMTEL MAkGA1UEBhMCREsxDDAKBgNVBAoTA1REQzEUMBIGA1UEAxMLVERDIE9DRVMg Q0EwHhcNMDkwMzE4MTk1MDUxWhcNMTEwMzE4MjAyMDUxWjB+MQswCQYDVQQG EwJESzEpMCcGA1UEChMgSW5nZW4gb3JnYW5pc2F0b3Jpc2sgdGlsa255dG5p bmcxRDAdBgNVBAMTFk5pa2xhcyBRdWFyZm90IE5pZWxzZW4wIwYDVQQFExxQ SUQ6OTIwOC0yMDAyLTItOTM5MTgxMjYzMjc1MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEDQR02RWeUSZivOB3sI0sS370IpKhBj9Op3a+JH2lTORu PatzFCVQGk5BAVG4fnIAn9i5YhkmY7KbeCEIQAYIjF8Nviyo1elov3zPwYho /wIwSnoUMaiE8PJr6bCNlo6nojveXZsNwjr4r47bX1PNUxTLMfUYQwcn9Gdc Ye+aOQIDAQABo4ICwzCCAr8wDgYDVR0PAQH/BAQDAgP4MCsGA1UdEAQkMCKA DzIwMDkwMzE4MTk1MDUxWoEPMjAxMTAzMTgyMDIwNTFaMIIBNwYDVR0gBIIB LjCCASowggEmBgoqgVCBKQEBAQEDMIIBFjAvBggrBgEFBQcCARYjaHR0cDov L3d3dy5jZXJ0aWZpa2F0LmRrL3JlcG9zaXRvcnkwgeIGCCsGAQUFBwICMIHV MAoWA1REQzADAgEBGoHGRm9yIGFudmVuZGVsc2UgYWYgY2VydGlmaWthdGV0 IGfmbGRlciBPQ0VTIHZpbGvlciwgQ1BTIG9nIE9DRVMgQ1AsIGRlciBrYW4g aGVudGVzIGZyYSB3d3cuY2VydGlmaWthdC5kay9yZXBvc2l0b3J5LiBCZW3m cmssIGF0IFREQyBlZnRlciB2aWxr5XJlbmUgaGFyIGV0IGJlZ3LmbnNldCBh bnN2YXIgaWZ0LiBwcm9mZXNzaW9uZWxsZSBwYXJ0ZXIuMEEGCCsGAQUFBwEB BDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3AuY2VydGlmaWthdC5kay9v Y3NwL3N0YXR1czAVBgNVHREEDjAMgQpuaWtAcW5pLmRrMIGEBgNVHR8EfTB7 MEugSaBHpEUwQzELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1REQzEUMBIGA1UE AxMLVERDIE9DRVMgQ0ExEDAOBgNVBAMTB0NSTDM3NTEwLKAqoCiGJmh0dHA6 Ly9jcmwub2Nlcy5jZXJ0aWZpa2F0LmRrL29jZXMuY3JsMB8GA1UdIwQYMBaA FGC1hexWZH4SGSdnHVAVS3OuO/kSMB0GA1UdDgQWBBTa2rwlMvwmyf0KN6TQ RrK53S8ryjAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjEDAgOo MA0GCSqGSIb3DQEBBQUAA4IBAQCWIF64PpPpC03RlTShEsckONm4GuCYbhnF YkoOhgrZ1HaCD4K1kTgWv75VKYxstlj+2UF2SUas3nVcooHUFLea9Vg/BFu2 RpMgVIa1EPzWROvV+xyuWRt0aTfoKb45cBPZUIVkvBragawn5dwAct6BHEUZ iyMUH41m50bE780nayKONIptp8N49dCxCUeVZcqrEe8cFaai/cV4UHt1Z3FT tB7q5y5FiE9PuOWw/VBS46UqiWs1tM4JNxa3hpq6DShIyzEiOkWjjOz990C9 3zSMbtFf/4hHcgqsIv43qQ1rYyeicaY1z+QgPHiNjfl2DYUJO9tavdTASeIs mX3ynDqkMYIB1TCCAdECAQEwOTAxMQswCQYDVQQGEwJESzEMMAoGA1UEChMD VERDMRQwEgYDVQQDEwtUREMgT0NFUyBDQQIERYneoTAJBgUrDgMCGgUAoIHz MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEw MDkyNzA4NTQwNVowIwYJKoZIhvcNAQkEMRYEFKy9iwkQ/u4z+snezJuuRcoY t2dFMEgGCSsGAQQBgjcQBDE7MDkwMTELMAkGA1UEBhMCREsxDDAKBgNVBAoT A1REQzEUMBIGA1UEAxMLVERDIE9DRVMgQ0ECBEWJ3qEwSgYLKoZIhvcNAQkQ AgsxO6A5MDExCzAJBgNVBAYTAkRLMQwwCgYDVQQKEwNUREMxFDASBgNVBAMT C1REQyBPQ0VTIENBAgRFid6hMA0GCSqGSIb3DQEBAQUABIGAbNxmARxuTe8c e2aOfxokP2zy4RV5tgwvgsamj20sYyEAYFLEsDvw8bzdTP6COfXksCq2+Eqd KvVj3+vh+cp1pz5vls4rNmRDnkvUurfCMdfsW7cVro3+RFhNI7+AjKjYcn8Y nHXJytYv/qcaVy0719QptHGBffNWAeK7HYIp6iMAAAAAAAA= --Apple-Mail-2-180283207--