From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=15.241.140.73; helo=g4t3427.houston.hpe.com; envelope-from=brian.johnson@hpe.com; receiver=edk2-devel@lists.01.org Received: from g4t3427.houston.hpe.com (g4t3427.houston.hpe.com [15.241.140.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1C397203555F8 for ; Tue, 14 Nov 2017 09:38:04 -0800 (PST) Received: from G2W6310.americas.hpqcorp.net (g2w6310.austin.hp.com [16.197.64.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3427.houston.hpe.com (Postfix) with ESMTPS id A5CFC5E; Tue, 14 Nov 2017 17:42:11 +0000 (UTC) Received: from G4W9122.americas.hpqcorp.net (2002:10d2:1511::10d2:1511) by G2W6310.americas.hpqcorp.net (2002:10c5:4034::10c5:4034) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 14 Nov 2017 17:41:30 +0000 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (15.241.52.10) by G4W9122.americas.hpqcorp.net (16.210.21.17) with Microsoft SMTP Server (TLS) id 15.0.1178.4 via Frontend Transport; Tue, 14 Nov 2017 17:41:29 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=brian.johnson@hpe.com; Received: from [10.0.2.15] (192.48.192.5) by DF4PR8401MB0411.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7606::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Tue, 14 Nov 2017 17:41:26 +0000 To: Andrew Fish CC: Paulo Alcantara , Fan Jeff , "edk2-devel@lists.01.org" , Rick Bramley , Laszlo Ersek , Eric Dong References: <8de9df9f-0386-8250-7c80-9a3cff65841e@zytor.com> <5aad56cd-ae69-59d3-1598-453a94926802@hpe.com> <1038F835-BDA5-4BAD-8032-25C12E2C1BF7@apple.com> From: "Brian J. Johnson" Message-ID: Date: Tue, 14 Nov 2017 11:41:37 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1038F835-BDA5-4BAD-8032-25C12E2C1BF7@apple.com> X-Originating-IP: [192.48.192.5] X-ClientProxiedBy: BN3PR03CA0094.namprd03.prod.outlook.com (2603:10b6:400:4::12) To DF4PR8401MB0411.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7606::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d00d2c3a-2281-4f09-bfaa-08d52b86ef43 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DF4PR8401MB0411; X-Microsoft-Exchange-Diagnostics: 1; DF4PR8401MB0411; 3:8/WzZl45GkcjvW6nQ85jioHMQ8JrJsywcPLouKFecQhBBF9tQTXvOGQV6guzdFMmbQ6AYnvDRo+PvKMGE1YXMNzJrS+CaNrw2y5lni8cKeADzrOPZPpjZ6j9sAZ6f9mKehSMRcdkroC8cTcLC02pGfgS69JgtwrgeZvwZAlhxnT4uxsV07A35NNh4QZJFCDzuOXT1XLfu35br0+DU7RDPQIT6YK4H5eW2yWZShzpJ0MlkvvoiJVOCcQwM1IlbxNl; 25:tKFWevM+eeWjCJkWGVVMBIUK7tq00tnLXuFaV8EEb74Ha0zOppYm8gi/2G6gwfSieYRMc6D9aXp27Pt7/VPXpvDPpMlhSSR1nzp25t1zeNGxUL75obz+Na7+wU+kapSpmQIU/SZNI5A4w8pOeLPg2rmtxs93E7Cbqo/H2YgS6/e1NBgmkW1AUW5obj6hAZePLdbvpuZ2MLaww3FhPXUhDF64LxBGOl9sL1MHO+HbauuNh9Euem6v4IhjpzRXu6wxaOqjy1Ys4ulwpmM8s2uVJzJoEoS42cT3nvpqrfh99Eg6ywoFy5pNmMyWmoXRwgaXLxytiz/eCzjdfnAzBy1VkA==; 31:Y3ELVQgLzfvzMWpGdttCxT+i54mxd4Ezlk2NCyl7+ED4kCzp3DdvRvzAsyM+sOjcSlkgRKWQ7YNyy/HorVcZ9Fc0Bs/13J+twqvuDpEkjOEc3k27FlXQi08oJMhKK6/mw/g+mMTE6PNfZFToqI48N+Z/5jt7/aVyE2Ipk8XhCm3MTQb42CPZcdv+keGvW0eQ5vZJDk/5JGRMMq4176y8csVZGiArh8IGBW80u7HE50Q= X-MS-TrafficTypeDiagnostic: DF4PR8401MB0411: X-Microsoft-Exchange-Diagnostics: 1; DF4PR8401MB0411; 20:Y7Rlp5FGdNv3gZMQA100CqrfD8Rx/DHcD48VKCRb9hdt4q3YrDAXlol06PAESw71x8zsg3TjaKIE/W463sgWImzHGPzGPbtu6TT9V/C8AGo0g8rYmoP58xdaW1avzBvzK9d2Snklgmc4MlIphrz8DCZnKGj7LtkDK2v3tRS9P7GjuuEBlRAwTiqUbaKHtgpieYG00qKUxmxdErB/AgFqGPXaDw9qjMS9Kd73azR7gDIlspKQm3upByRlPadj9GDW8GpPLZvNviVdrgoqugopJ5//3K2NeZE/CtYq1lw37rxr0oc4bHFasNZEyUwobbqs1wFsPky7UbBKrNZ+asId26Q6t1GkXrG1OJq9xwKJohudPtbRYxl7QL3UDLXbzlxDRpeXiJzSZcTrqaXhnvH0dE+kRsUzRvHlP1vNlRc08WnGIrrlgK6bCb0X/cUmI/dXKUXvet00sIYPxS/95OS4+oyi2Gyfp0LT+Q85DZJzH0TFg8o9sXkJR2VHg3O2S70u X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(80524489315369)(227479698468861)(166708455590820)(162533806227266)(31960201722614)(228905959029699)(73583498263828); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231022)(100000703101)(100105400095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DF4PR8401MB0411; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DF4PR8401MB0411; X-Microsoft-Exchange-Diagnostics: 1; DF4PR8401MB0411; 4:sRhWd7n0jDsF/k61HoRS2LBPEo5zixGAX3R9V+ylQmIJwHtQzzXuM5Al/Q0Rr07SgyExtVCRj+5eQ5fOX2gEkgKUSoFG31G5QHspgNS+Jp9/OcgNGEA5iyMvtWAYgDYjBZhOwV5GN3TUp47QK5r1E4vDdMo3sGzCcGAo4g+1IeEVRQvXkqyRmLLHziWeajMQ5OBMl5Ufjys+Qty1Mi9IjJqQsXYdo9rcgDzy6thK4s7cKpZqEKYE9KNMyze/eK+uqAHS4inKQWUdYr4oREwm+6qGocFFFoMVsCrB5CSkuLXAGoVwLpzONOVH/x+8+Rt+xAOr47vB2m5Q/QyCar32sXmlpih3VZYugCEiZktNPQCTvkX/17Jd432AanpBJoJUiv6sg8yxDoQXHEoHNwq7jEr7HNxt6dWa1yz5LH+MTutXfaF1VNmjvxioVfRm4D4o6/oOPe0oBHgK4dwMChA3ejL+vxVmJzo55BXyJ/Zrssx8GUgviKDckDCWb5wabXGcihEyw1tuO1MRooF/mTt1sg== X-Forefront-PRVS: 04916EA04C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(39860400002)(376002)(346002)(45984002)(189002)(199003)(24454002)(48014003)(76104003)(966005)(50986999)(6486002)(53936002)(25786009)(8666007)(316002)(23676003)(64126003)(53546010)(93886005)(67846002)(76176999)(6306002)(305945005)(101416001)(478600001)(97736004)(50466002)(45080400002)(54906003)(65806001)(4326008)(65956001)(16576012)(66066001)(54356999)(229853002)(6246003)(77096006)(2870700001)(189998001)(47776003)(58126008)(39060400002)(5890100001)(8676002)(6116002)(8936002)(6666003)(86362001)(36756003)(2906002)(31686004)(33646002)(2950100002)(7736002)(31696002)(105586002)(5660300001)(83506002)(106356001)(3846002)(6916009)(16526018)(68736007)(81166006)(65826007)(81156014)(460985005); DIR:OUT; SFP:1102; SCL:1; SRVR:DF4PR8401MB0411; H:[10.0.2.15]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtERjRQUjg0MDFNQjA0MTE7MjM6aHE4S1o3cWlKaXlycTMvbzFQcGtTQWR2?= =?utf-8?B?QmE0RnZtSDVSZjVkWEFaWG16RFVCK0tYRGVxS3lxV1NjYUtFeVFNa0FWVmZt?= =?utf-8?B?Z001SVJtc2NRUFRwVFFoN1l4NU40SjVXSm9qOXMwWUdqZERXeVJ5QUg3K1dZ?= =?utf-8?B?UWtsYnNGU3lIenYyK0pKS2gwcVFjNGZ5TEtSbE1waENIYlNyT3hPUDJnQjZM?= =?utf-8?B?TFFUcHpxQnBIZlNaM0FLYnZkVHR1Mmd2bGMvZWd0T0g5Qms5NS9UaWFEaExG?= =?utf-8?B?M3Zkd1hCWm5HVjN5b0RROUtmckpNMFpqZXFZTHNnZ0Ivbm42NjVpczZmZndl?= =?utf-8?B?VHBpVEZOc0xkMmtuWVRTR1lvVDdoWCthYjJ0WFVscU40UEJiTUptWStIWEpi?= =?utf-8?B?VFhCbkVMM0VjNkgrZ2FFcEVRTEJhRHNRbmNodnNGWGhCdjRTcEZXSEQ1MEdO?= =?utf-8?B?QmZ2L3RveC9lekl0RzJidElyc0pmMkI2dzBnVjB0ODBGeDBIYzFndmY1cU1B?= =?utf-8?B?eUxVSm81aldlM1NJQitBa3NBa0EzSWh5Rytoekt1VkpmcUhwaFdvaThDWjVR?= =?utf-8?B?d0tSOUZwUFNJNk1GdGV4RGZ0WWNQMStpeG11QlJsYUVlaWdzKy9iaGNHVTBP?= =?utf-8?B?dzJ3Rkxzc1B4bEM0ZVBWbU85UTJKVkRuSTlRNm81UzZZR3JoaStCRnpsODZs?= =?utf-8?B?THpQcEplVW1LUkFFNEVKbnRCQTNKK3AraFBzNkxQT3poZWVNZmFOWXUxbmFs?= =?utf-8?B?aDM0czlncGkzeXlJQmJTbDFCV2NoYzRBSzJBaThPcXoxSm9sZTk1MEpwN0d4?= =?utf-8?B?dVAwZFcreG1ZMU1vWEVuRm1pL2xnOFMzYVdQcWdqOGhPVmVlMVYrTVFQeEh5?= =?utf-8?B?Y0x1SWVneTB3ZHI4UGRDYjRUTXFyQ2N4SlkwRlF0U1dXc0RUT2tYamJienhB?= =?utf-8?B?ZVFVUi9FM1l3YmxXa1V4c0xDdWRVRzRzcjE5dXBmZWM0Y3hxUzgxOFV0clFT?= =?utf-8?B?MkwvVG5QdW5FdDljUFdZcXNwbUtCd3licTV1TkxwQ29NTTRaTEhwVm1qMWZv?= =?utf-8?B?TjVnRUg3KzNMeU5zQ0NVclZMZXVpUXF4RUpNbHl2eXlFeXZub1BCdVpkS21z?= =?utf-8?B?Y1NFa3pBR3VRRGkzWGRPSU9GL3Z3V2o5OU1pRDBPak5ybEQyZFUwYm1jVy9V?= =?utf-8?B?MmtZTmpISXhUaEZ1NHdpYTA0Vnc5QjF5N0tSYklpZFk5bFBLZ0VvdWxtZXFG?= =?utf-8?B?aHdsWis2VmFDSWdrUlErN1JoWFdNdVlVMVlVeUxHa2lXY3cyN2ZhU2hLU2oz?= =?utf-8?B?TWVZOTN6Z0VNTm5LWjI1dzN4bGR2Q2h2U1BsVVc4RFFLdnhmNmNWU3ZRL1Zs?= =?utf-8?B?dGN2UUgzaVZZT0UrQU1TZ1JRTzlwWHlZUkdNVlQ4NHJOekRGZ2pYeXBZTHAv?= =?utf-8?B?SVd6RzZOYjhmZnlpajhpMjk0Z2hsODgwT1lDS3lxcm9oSS9lZ0psS09KV0ZC?= =?utf-8?B?Q2hNT2NSYTRKNENSYUJpSENtM3hiWjZaS0JjZFVodDZrTE0wY1RhRnBSMUxn?= =?utf-8?B?T3R4RktCTE5KVENXNlU0eG5zcUFNZitpakhkRjdrUk5wWW1TaVVRWnBHTGxS?= =?utf-8?B?YWlFOENGa3YwRDFUU2tTM3hlZ1l1QzlGb3F5Y245QzUwSVExOXVFaEVFR1d4?= =?utf-8?B?ZUYyUk1wWEtrazlyNklYUFo1Y3dUZFRLT2dkVytsTzVub0ZzS3dYb1NXYnVW?= =?utf-8?B?c0Z6YXRHTU5KWUYxT1NuVWFMUEhUWkFEamJoNGovaVVMUWkxY0JWV2lUY3Fo?= =?utf-8?B?ZlEreGpWSHFza29nUkZBSCtTc1RkalM5T1RKNDNWMDhyT2ZBZjZibDJxeFJo?= =?utf-8?B?RHgvemF0U1p4bXVJZ20rSkd2UDU0Ui8vMFZacXVVa202c1RyaXovQzd1ZFlU?= =?utf-8?B?d3YzdnZ0TTNsVUdrODVXUGJhUVltSEU4Z1JwSDFOb2dCTTJlU2Q3MHMrd3hw?= =?utf-8?B?bU5JeWtmUzBWU1AwWGFTdjhiYXVnVm1lVmw2T3o1M21lY0V1cTFVd2l5elNi?= =?utf-8?B?R1JoR0VENnowZkdsWThZRnhabWdFQmFwYVM3TWFpKzd4eCtJdVBXaUFVeGIx?= =?utf-8?B?WmpTeGtHT3R6Zkd1ZEczd3hXTjlZejhhaE52V3N0NjJCZTgwbmVqZFFHckVj?= =?utf-8?Q?9JTA0o7e6rzi9GL8FynH47e+JD7XMr+XPzZqXpB6aF/o=3D?= X-Microsoft-Exchange-Diagnostics: 1; DF4PR8401MB0411; 6:9A6L05qOcDs2KWORxVz1XPNvXSdOrhacQZyeccTF4Rgnsk26oz6lSgk9yM9h0tc+3lm+rPT5nv3/G/GEHsm66HGWXRnWLHEzu2MFKwE6JrCgEig6m9Mj+eiTu0aKXUOwnqVRiEDepqzzJxP+0C8xq0PV8kus0lDi4kE6BBtcXptizax4C7/6UWrnHHQMF297/EnEQKWSnTyAAHY/9cUbhe4JIQOXebygpuVJDtSHso/j4500char+YvPdAWN9VpAlBDc44Pqs80VMgKSlGZMxKsE+TixfP3H360O0y2WOirD2pTDChcY4C2+qK1dzMGL+E88Y7n5ZE/nbusQJfOcbCcjJE/65TE4bYF1mnEyG6Y=; 5:n+AL51eWNCIpm7abABn8Hmre5ZKiY16M8aisTYcWiPavuX0nswB80fi5Oy0TRT6Nr9QzUm/PkVneXUp2/TQ5OZf3hK1HFLlnw8r77or5Ib12EQ5X85mgqZToJ7phODif+pUdDnjgPxi+wNNlTzSAElKHq5TmVNnVNhCArkF98Ec=; 24:0AxexfuygZN3/1drIPzCIfO1vzoq8qkSdp3QkPtY41HoW4E6tHo70skydJcnkHB99c03wduEKoZwWaxzSII3rlJSd1didi5+18p4id4k3JQ=; 7:DY0J1SDpa36ZLMBLjQ9J5Ghc2NmIOcBU1lBvpsdZ8p4vNxyBobkEtWTVPSlcMg53rdsFkyUTMesbacq+lHw3cQDP3UMLxvGj1DY0np+M/mLk8fWWkwid6HZ3qnWapY59XKUKUQx5owkGlgeA2qBYqmn0BFhCv22hbjKCN3rmwOVxk/Fd8M4IXICo7H0tfOaMMDderYqUQkX9rF7fCtbV0X8HxsBex1I+v2odqLvGbKej5jjeiaf4YdXHad5U/+sf SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2017 17:41:26.2287 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d00d2c3a-2281-4f09-bfaa-08d52b86ef43 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR8401MB0411 X-OriginatorOrg: hpe.com Subject: Re: [RFC 0/1] Stack trace support in X64 exception handling X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 17:38:05 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit On 11/14/2017 11:23 AM, Andrew Fish wrote: > >> On Nov 14, 2017, at 8:33 AM, Brian J. Johnson > > wrote: >> >> On 11/14/2017 09:37 AM, Paulo Alcantara wrote: >>> Hi Fan, >>> On 14/11/2017 12:03, Fan Jeff wrote: >>>> Paul, >>>> >>>> I like this feature very much. Actually, I did some POC one year ago >>>> but I did finalize it. >>>> >>>> In my POC, I could use EBP to tack the stack frame on IAS32 arch. >>>> >>>> But for x64, I tried to use –keepexceptiontable flag to explain >>>> stack frame from the debug section of image. >>>> >>>> I may workson MSFT toolchain, but it did now work well for GCC >>>> toolchain. >>>> >>>> I think Eric could help to verify MSFT for your patch. If it works >>>> well, that’s will be great! >>>> >>>> Say again, I like this feature!!!:-) >>> Cool! Your help would be really appreciable! If we get this working >>> for X64 in both toolchains, that should be easy to port it to IA-32 >>> as well. >>> Thank you very much for willing to help on that. >>> Paulo >> >> Great feature!  You do need some sort of sanity check on the RIP and >> RBP values, though, so if the stack gets corrupted or the RIP is >> nonsense from following a bad pointer, you don't start dereferencing >> garbage addresses and trigger an exception loop. >> > > Brian, > > This was a long time ago and my memory might be fuzzy.... I think we > talked to some debugger folks about unwinding the stack and they > mentioned it was common for the C runtime to have a return address or > frame pointer have a zero value so the unwind logic knows when to stop. > This is in addition to generic sanity checking. > > We got an extra push $0 added to the stack switch to help with stack > unwind. > https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/SwitchStack.S > > If might be a good idea to have a PCD for the max number of stack frames > to display as a fallback for the error check. For X64 you may also have > to add a check for a non-cononical address as that will GP fault. > Good idea. Regarding sanity checks: I've had good luck validating code locations (EIP values) by using a modified PeCoffExtraActionLib to track the top and bottom of the range where images have been loaded. (I've actually used two ranges: one for code executed from firmware space, and one for code executed from RAM.) I'm not sure offhand if there's a platform-independent way to validate stack pointer values. For most PC-like systems, just ensuring that it's larger than 1 or 2M (to avoid NULL pointers and the legacy spaces) and less than about 3G (or the low memory size, if that's known) may be enough to avoid an exception loop. Brian > Thanks, > > Andrew Fish > > >> For at least some versions of Microsoft's IA32 compiler, it's possible >> to compile using EBP as a stack frame base pointer (like gcc) by using >> the "/Oy-" switch.  The proposed unwind code should work in that case. >> The X64 compiler doesn't support this switch, though. >> >> AFAIK the only way to unwind the stack with Microsoft's X64 compilers >> is to parse the unwind info in the .pdata and .xdata sections. >>  Genfw.exe usually strips those sections, but the >> "--keepexceptiontable" flag will preserve them, as Jeff pointed out. >>  I've looked hard for open source code to decode them, but haven't >> found any, even though the format is well documented.  And I haven't >> gotten around to writing it myself.  I'd love it if someone could >> contribute the code! >> >> Another possibility is to use the branch history MSRs available on >> some x86-family processors.  Recent Intel processors can use them as a >> stack, as opposed to a circular list, so they can record a backtrace >> directly. (I'm not familiar with AMD processors' capabilities.)  You >> can enable call stack recording like this: >> >>  #define LBR_ON_FLAG   0x0000000000000001 >>  #define IA32_DEBUGCTL 0x1D9 >>  #define CALL_STACK_SET_FLAG 0x3C4 >>  #define CALL_STACK_CLR_FLAG 0xFC7 >>  #define MSR_LBR_SELECT 0x1C8 >> >>  // >>  // Enable branch recording >>  // >>  LbControl = AsmReadMsr64 ((UINT32)IA32_DEBUGCTL); >>  LbControl |= LBR_ON_FLAG; >>  AsmWriteMsr64 ((UINT32)IA32_DEBUGCTL, LbControl); >> >>  // >>  // Configure for call stack >>  // >>  LbSelect = AsmReadMsr64 ((UINT32)MSR_LBR_SELECT); >>  LbSelect &= CALL_STACK_CLR_FLAG; >>  LbSelect |= CALL_STACK_SET_FLAG; >>  AsmWriteMsr64((UINT32)MSR_LBR_SELECT, LbSelect); >> >> The EIP/RIP values are logged in MSR_SANDY_BRIDGE_LASTBRANCH_n_FROM_IP >> and MSR_SANDY_BRIDGE_LASTBRANCH_n_TO_IP, and the current depth is >> tracked in MSR_LASTBRANCH_TOS.  This works quite well.  Gen10 (Sky >> Lake) processors support 32 LASTBRANCH_n MSR pairs, which is >> sufficient in almost all cases. >> >> Different processor generations have different branch recording >> capabilities, and different numbers of LASTBRANCH_n MSRs; see Intel's >> manuals for details. >> >> Thanks, >> Brian >> >>>> >>>> Thanks! >>>> >>>> Jeff >>>> >>>> *发件人: *Paulo Alcantara >>>> *发送时间: *2017年11月14日21:23 >>>> *收件人: *edk2-devel@lists.01.org >>>> >>>> *抄送: *Rick Bramley ; Laszlo Ersek >>>> ; Andrew Fish ; >>>> Eric Dong >>>> *主题: *Re: [edk2] [RFC 0/1] Stack trace support in X64 exception >>>> handling >>>> >>>> Hi, >>>> >>>> On 14/11/2017 10:47, Paulo Alcantara wrote: >>>>> Hi, >>>>> >>>>> This series adds stack trace support during a X64 CPU exception. >>>>> >>>>> Informations like back trace, stack contents and image module names >>>>> (that were part of the call stack) will be dumped out. >>>>> >>>>> We already have such support in ARM/AArch64 (IIRC) exception handling >>>>> (thanks to Ard), and then I thought we'd also deserve it in X64 and >>>>> IA-32 platforms. >>>>> >>>>> What do you think guys? >>>>> >>>>> BTW, I've tested this only with OVMF (X64 only), using: >>>>> - gcc-6.3.0, GCC5, NOOPT >>>>> >>>>> Any other tests  would be really appreciable. >>>> >>>> I've attached a file to show you how the trace would look like. >>>> >>>> Thanks! >>>> Paulo >>>> >>>>> >>>>> Thanks! >>>>> Paulo >>>>> >>>>> Repo: https://github.com/pcacjr/edk2.git >>>>> Branch: stacktrace_x64 >>>>> >>>>> Cc: Rick Bramley >>>> > >>>>> Cc: Andrew Fish > >>>>> Cc: Eric Dong > >>>>> Cc: Laszlo Ersek > >>>>> Contributed-under: TianoCore Contribution Agreement 1.1 >>>>> Signed-off-by: Paulo Alcantara >>>> > >>>>> --- >>>>> >>>>> Paulo Alcantara (1): >>>>> UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support >>>>> >>>>>   UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c >>>>> | 344 +++++++++++++++++++- >>>>> 1 file changed, 342 insertions(+), 2 deletions(-) >>>>> >>>> >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >> >> >> -- >> >>                                                Brian >> >> -------------------------------------------------------------------- >> >>   "Most people would like to be delivered from temptation but would >>    like it to keep in touch." >>                                           -- Robert Orben >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > -- Brian J. Johnson Enterprise X86 Lab Hewlett Packard Enterprise brian.johnson@hpe.com