跳到主要內容

Export DLL Symbols

終於可以開始 debug DLL project 了!

之前根據 Debugging DLL Projects 的設定,
設定好 debug property 的 caller 並且在 DLL project 裡面設定中斷點,
但是 caller 一被叫起來後,馬上就 exit code 1,
並沒有 hit 到在我在 DLL project 裡設定的中斷點.

原本以為可能是我設定的中斷點不是 entry point ,程式提早結束所以沒有 hit 到.
想一想拿 sample code build 出來的 DLL 去測試,發現 entry point 是對的,
DLL debug 的中斷點在 sample code project 裡面也可以正常的 hit 並且停止.

想了很久後再看一次 caller 的文件,發現可以提高 caller 的 debug level ,
所以可以驗證我的另一個猜測,看是不是我指定的 DLL 其實並沒有被載入?
結果 debug log 顯示, DLL 應該是有被正確載入.
但是為什麼 caller log 會一直顯示載入 entry point function 失敗呢?

突然想到,我的 DLL 真的有 export 該 function 嗎?
Dependency Walker 去分析我的 DLL ,
發現 x86 build 確實有 export function,但是 x64 build 卻是空白的?
這時候我開始想說,難道是 build configuration 有問題?
但是 x86 build 的 DLL caller 也是無法正確載入啊?
那先不管 x64 build 好了,感覺 x86 build 比較有機會突破阻礙.

那再來比較 x86 build export 的 function 和 sample code 的有什麼不一樣
仔細一看,原來是 function name 被 mangling 處理過,多了 "_" prefix.
設定好 DLL project 的 def 檔重 build 後, caller 果然可以載入成功並且 hit 中斷點.
而神奇的 x64 DLL export function 是空白的現象也恢復正常了!

原來要 build 一個 DLL 有這麼多眉角要注意,學到這些東西很開心 :)


留言

這個網誌中的熱門文章

Access private API gateway from another account

最近在做一個 PoC 驗證說怎麼在現有的架構下,把一些 public API 移到 VPC 裡面,只讓特定網路的人可以存取。 當然最直覺的想法就是,建一個新的 VPC ,加上 execute-api VPC endpoint 然後這個 VPC 再跟特定網路做 Peering,建一個 Private API Gateway 在新的 VPC 裡面。 這樣新的 VPC 可以透過 VPC endpoint 去存取 API Gateway,然後再加一個 ALB ,裡面的 target group 指向 VPC endpoint 的 IP和 443 port,ALB 設定好 Domain Listener,API Gateway 也加上相同的 Custom Domain Name,這樣子 ALB 就可以當成特定網路 access 的 entry point,一但 Peering 完成後,從特定網路來的 request 就可以經由 ALB -> API GW 跨 VPC 存取原本環境的 backend resource。 但我一直在想,Peering 是必要的嗎? 沒想到隔天就看到這個教學  How can I access an API Gateway private REST API in another account using an interface VPC endpoint?  裡面的做法突破了原本我直覺上的盲點! 就是即使是 Internal API Gateway 似乎只要設定好了 resource policy 就可以允許其他 account 的 VPC endpoint 跨帳號存取! 所以例子裡面的 private API Gateway 是建立在 B 帳號裡面,A 帳號的 VPC 只是啟用了 VPC endpoint,一但 B 帳號的 private API Gateway 在 resource policy 設定好允許 A 帳號的 VPC endpoint 存取,即使兩個帳號之間沒有 peering 也是可以互通的! 雖然說這樣子要帶 hostname header or api-gw-id 但是 原本架構上的 ALB 也是為了 VPC endpoint 可以知道要 forward request 給哪個 API Gateway ...

全球鷹/響尾蛇 D300 行車記錄器

全球鷹 Global Eagle /響尾蛇 D300 行車記錄器 前後雙鏡頭,透過電瓶的壓升壓降來開啟/關閉行車記錄器主機 wifi 是 mmcx 接頭,去淘寶買一條 20 元 預設 wifi 密碼是 12345678 透過 TimaCam 可以 wifi 連線主機,用來看即時鏡頭畫面還可以 但是要下載一個片段 216MB 非常慢,讓我看到噪音管和吐白煙的想檢舉也覺得麻煩... 主機拆下後,即使透過 USB 供電也無法開機, 要操作主機只能發動機車在車子旁邊操作, 主機沒接線的裝態也不能直接拿來看錄影檔。 從 2018.3 月安裝到現在,發生過一次熄火吃完飯(約20分鐘),竟然沒關機還在錄影。還好只是 20 分鐘,不然電瓶的電不知道會不會被吃完。 現在都很提心吊膽,熄火後都會等他壓降關機後(約 1 分鐘)才會離開。 早知道還是裝一般開電門供電,關電門關機的機種。 wifi 看檔和安裝容易都只是噱頭,買了才知道難用。

Publish lambda layer to regions from s3 bucket?

boto3 有個  publish_layer_version  API,你可以使用 S3 bucket + key or zipfile 來發布 lambda layer. 使用 zipfile 的話就是從命令執行端上傳,所以假設你的 lambda packet 是 20MB 然後你要發佈到 16 個 AWS region 的話,就看你命令執行端的網路上傳速度了。 使用 S3 bucket 來放要發佈的 zipfile 檔似乎比較合理,因為這樣子檔案的複製就是在 AWS 的網路內發生。 But... 很機車的是,如果你的 zipfile 是放在 us-west-1 的 S3 bucket 那麼你就只能發佈到 us-west-1 .... 當你要發佈到其他 region 會出現 error botocore.errorfactory.InvalidParameterValueException: An error occurred (InvalidParameterValueException) when calling the PublishLayerVersion operation: Error occurred while GetObject. S3 Error Code: PermanentRedirect. S3 Error Message: The bucket is in this region: us-east-1. Please use this region to retry the request S3 bucket name 是 global unique 但其實 bucket 位置是有 region 的... 目前還沒有看到什麼比較好的方式來發佈 lambda layer 到全部的 region.... replicate 所有的 zipfile 到所有的 region, 然後每個都有自己的 bucket name 似乎蠻蠢的?....