aboutsummaryrefslogtreecommitdiff
path: root/elfcpp/ChangeLog-0815
diff options
context:
space:
mode:
authorHannes Domani <ssbssa@yahoo.de>2023-12-06 20:52:06 +0100
committerHannes Domani <ssbssa@yahoo.de>2023-12-06 20:56:49 +0100
commit2574cd903dd84e7081506e24c2e232ecda11a736 (patch)
tree06f7ef7c4e9236ab2e91c12b5c62b580b0d14d3e /elfcpp/ChangeLog-0815
parenta70364f6b4ca2a57876d98300b9933d3d1348e72 (diff)
downloadgdb-2574cd903dd84e7081506e24c2e232ecda11a736.zip
gdb-2574cd903dd84e7081506e24c2e232ecda11a736.tar.gz
gdb-2574cd903dd84e7081506e24c2e232ecda11a736.tar.bz2
Fix DLL export forwarding
I noticed it when I was trying to set a breakpoint at ExitProcess: ``` (gdb) b ExitProcess Breakpoint 1 at 0x14001fdd0 (gdb) r Starting program: C:\qiewer\heob\heob64.exe Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x3dbf4120 Cannot insert breakpoint 1. Cannot access memory at address 0x77644120 ``` The problem doesn't exist in gdb 13.2, and the difference can easily be seen when printing ExitProcess. gdb 14.1: ``` (gdb) p ExitProcess $1 = {<text variable, no debug info>} 0x77644120 <UserHandleGrantAccess+36128> ``` gdb 13.2: ``` (gdb) p ExitProcess $1 = {<text variable, no debug info>} 0x77734120 <ntdll!RtlExitUserProcess> ``` The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a, where VMA was then calculated relative to FORWARD_DLL_NAME, while it was relative to DLL_NAME before. Fixed by calculating VMA relative to DLL_NAME again. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31112 Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'elfcpp/ChangeLog-0815')
0 files changed, 0 insertions, 0 deletions