liteldev / peeditor Goto Github PK

原exe不存在此问题，可以正常启动调试
据报告，vscode同样也无法启动调试，目测不是clion附带的lldb的问题

LiteLoader generated executable is locked to the generated name, and cannot be renamed due to library import calls. This makes it difficult to track multiple running servers on a single machine, a feature found useful by many. I created a pull request yesterday with what I believe is a flawless answer to such a problem.

A command-line option of: LLPeEditor.exe -o "MyBedrock.exe" will:

     * Name the generated output executable as "MyBedrock.exe".
     * Automatically scan all plugins for imports targeting "bedrock_server_mod.exe", and when found
rebuild them with the import renamed to "MyBedrock.exe". File is unmodified if there are no matching imports.

Lastly, it also occurred to me that plugins are built also targeting a hard-coded "bedrock_server_mod.exe". I understand the nature of this, and so I also ensured that running the command: LLPeEditor.exe -o "MyBedrock.exe" -p will:

 * Turn off all generation of files
 * Quickly process all affected plugins and exit.

My goal is to add the ability for users to one-click build their existing or new server setup into a LL modded server, then take advantage of some new added functionality added via the console. The GUI interface behind this service can also be made responsible for remote management of selected or desired plugins pretty quickly.
The availability of these options will add a great deal of flexibility to LiteLoader, and should be considered!

Thank you all for all of your hard work!

Hello again folks! I spotted a bug today after noticing the executable I built following your formula contained less exports than built with PeEditor. I dumped the PE section and found that exports starting with "?$TSS" were found within the modded executable. After a quick look, I found a comma missing after "?$TSS" within the array. After fixing the comma, building, and running LLPeEditor, the exports directory contains 0x3D99 exports, where it once contained 0x6142 exports.

C函数没有name mangling，由于过滤符号时去掉了所有不以?开头的符号，使得导出的lib中没有任何C函数符号。但部分函数是有用的，如quickjs的函数均是extern "C" 的。用例：https://github.com/cuixiang0130/add-module-to-addon

RT，方便用户

Describe the bug
在非Tools下级目录（即，LibraryBuilder.exe同级目录）调用LibraryBuilder.exe时，在"Running SymDB2"和"Running LLVM-DLLTool"阶段出现错误。

To Reproduce
（此处以LiteLoaderSDK为例，并假设复现者已克隆LiteLoaderSDK至本地）

1. 在LiteLoaderSDK的同级目录执行./LiteLoaderSDK/Tools/LibraryBuilder.exe -o ./lib。
2. 选择对应的bds目录。

Expected behavior
出现系统找不到指定的路径。的提示，同时lib生成失败。

Screenshots or log

Environment (please complete the following information):

• OS: Windows 11
• LiteLoader Version 2.1.0

Additional content
建议：

1. 加入参数，使得用户可以自行选择LLVM-DLLTool和SymDB2的目录。
2. 从LibraryBuilder.exe所在目录的llvm-dlltool-msys2目录下调用llvm-dlltool.exe，而不是从调用LibraryBuilder.exe的目录下的llvm-dlltool-msys2目录下调用llvm-dlltool.exe（即，使用${exe_path}/llvm-dlltool-msys2/llvm-dlltool.exe，而不是./llvm-dlltool-msys2/llvm-dlltool.exe），SymDB2同理。