标签: loader

我正在使用GNU binutils在Windows上使用程序集构建一个dll.

我知道可以在加载可执行文件时或在运行时加载dll(使用LoadLibrary api调用).

对于加载时加载,我似乎只需要dll文件:不需要.a,.lib或.def文件.我想知道这些文件格式代表什么,它们的用途是什么.

我所知道的和一些具体问题:

• .a是Unix上通常用于静态库的扩展..a文件是使用GNU ld 的--out-implib选项生成的.它被认为是一个"进口图书馆",足够公平.问题是"如果我在链接时不需要它,那对我来说有什么用？"

• .lib是Windows上用于静态库的扩展,根据维基百科,在windows下也被用作"导入库",所以我强烈怀疑它们只是binutils调用.a文件的另一个名称.真假 ？

• 我可以找到的所有页面都指出.def文件列出了dll的导出符号.这与"导入库"应该做的有点类似吗？

• 另外,我在这里读到使用.def文件是在源文件中手动指定导出的替代方法(我做过).但我还记得读取(找不到引用).def文件为导出的符号提供索引(序号),允许更快的运行时加载.是这样吗 ？

如果它们都包含已编译的代码,为什么我们不能在运行时加载"静态"文件,为什么我们不能在编译时链接动态库？为什么需要单独的格式来包含"独立"代码？什么需要存储哪个保证差异？

将程序加载到内存中时,加载时动态链接和运行时动态链接有什么区别？

当说3个程序(可执行文件)被加载到内存中时,布局可能如下所示:

alt text http://img97.imageshack.us/img97/3460/processesm.jpg

我有以下问题:

1. 虚拟内存的概念是否仅限于用户进程？因为,我想知道操作系统内核,驱动程序在哪里？它的内存布局如何？我想更多地了解内核端内存.我知道它的操作系统特定的选择(windows/linux).

2. 是每个进程虚拟内存的概念吗？我的意思是说我说4GB的进程1 + 4GB的进程2 + 4GB的进程3 = 12GB的虚拟内存(对于所有进程)是正确的.这听起来不对.或者从总共4GB空间内核占用1GB,其余3GB共享b/w所有进程.

3. 他们说,在4GB地址空间的32位机器上.其中一半(或最近1GB)被内核占用.我在这个图中可以看到"内核虚拟内存"占用0xc0000000 - 0xffffffff(= 1 GB).他们在谈论这个吗？或者是别的什么？只是想确认一下.

4. 什么究竟做了Kernel Virtual Memory每个流程的内容？它的布局是什么？

5. 当我们做IPC时,我们谈论共享内存.我没有看到这些进程之间共享任何内存.它在哪里生活？

6. 资源(Windows中的文件,注册表)对所有进程都是全局的.因此,资源/文件句柄表必须位于某个全局空间中.那个区域会是什么？

7. 我在哪里可以更多地了解这个内核方面的东西.

只是看不到模型导入到three.js场景中.几何图形看起来很好,但无论我应用哪种材料,模型都不会显示.

我是WebGL的新手,所以我很难诊断,但我的猜测是在JSONLoader回调期间出现了问题.

谢谢你的帮助.

var camera, scene, renderer, mesh, loader;

init();
animate();

function init() {

    camera = new THREE.PerspectiveCamera( 75, window.innerWidth / window.innerHeight, 1, 10000 );
    camera.position.z = 1000;

    scene = new THREE.Scene();

    loader = new THREE.JSONLoader();

    loader.load( "scripts/model.js", function( geometry ) {
        mesh = new THREE.Mesh( geometry, new THREE.MeshNormalMaterial() );
        mesh.scale.set( 10, 10, 10 );
        mesh.position.y = 150;
        mesh.position.x = 0;
    } );

    scene.add( mesh );

    var ambientLight = new THREE.AmbientLight(0x555555);
    scene.add(ambientLight);

    var directionalLight = new THREE.DirectionalLight(0xffffff);
    directionalLight.position.set(1, 1, 1).normalize(); …

我有一个 Vue2 的 Vite 项目，它包含一个静态 html 文件。

喜欢关注

import template from 'editor.html';\nexport default {\n    template: template\n}\n

当我运行时yarn dev，终端输出：

\n

node_modules/@gaoding/editor-framework/lib/base/editor.js:23:21：错误：没有为“.html”文件配置加载器：node_modules/@gaoding/editor-framework/lib/base/editor.html \n23 \xe2\x94\x82 从 './editor.html' 导入模板；

\n

我尝试在下面添加一些插件vite.config.ts，但所有这些都不起作用。

\n

@rollup/插件-html

\n

\n

rollup-插件-html

\n

\n

rollup-插件-htmlvue

\n

我怎么解决这个问题。

我想弄清楚我是否在装载机方面做错了.我正在使用支持库,我有一个片段,在onCreate()中调用initLoader()将其自身设置为LoaderCallbacks,但是在旋转时它会在onLoadFinished()中接收两次结果,一次调用init (并且它已经拥有数据),并且一旦FragmentActivity循环遍历onStart()中的所有Loaders并提供结果,因为它已经拥有数据.

如果我只调用init一次(在首次启动Fragment时),它不会将自己设置为Loader的回调,因此它根本不会接收对onLoadFinished的调用.好像onLoadFinished应该只被调用一次,因为onLoadFinished()可以完成一些昂贵的事情(例如清除列表适配器等),所以我只想弄清楚这是一个bug还是我是只是在错误的时间或其他地方调用init.

任何人都对此问题有任何见解？

我正在Linux下编写一个简单的用户空间ELF加载器(为什么？为了'有趣').我的加载器目前非常简单,只能加载包含与位置无关的代码的静态链接的ELF文件.

通常,当程序由内核的ELF加载程序加载时,它会被加载到自己的地址空间中.因此,数据段和代码段可以加载到ELF段中指定的正确虚拟地址.

但是,在我的情况下,我通过内核请求来自内核的地址mmap,并且可能会或可能不会获得ELF段中请求的地址.这对于代码段来说不是问题,因为它与位置无关.但是,如果未在预期地址处加载数据段,则代码将无法正确引用存储在数据段中的任何内容.

实际上,我的加载器似乎可以正常使用不包含任何数据的简单程序集可执行文件.但是一旦我添加数据段并引用它,可执行文件就无法正常运行或SEGFAULTs.

如果可能的话,我如何修复对数据段的任何引用以指向正确的位置？为此目的,是否在(静态)ELF文件中存储了重定位部分？

场景:我正在使用Managed Extensibility Framework在运行时根据在单独的dll中定义的接口契约加载插件(导出).在我的Visual Studio解决方案中,我有3个不同的项目:主机应用程序,类库(定义接口 - "IPlugin")和另一个实现接口的类库(导出 - "MyPlugin.dll").

主机在其自己的根目录中查找导出,因此在测试期间,我构建整个解决方案并将Plugin.dll从Plugin类库bin/release文件夹复制到主机的调试目录,以便主机的DirectoryCatalog可以找到它并且能够将它添加到CompositionContainer.每次重建后都不会自动复制Plugin.dll,所以每次我对合同/实现进行更改时都会手动执行.

但是,有几次我运行主机应用程序而没有首先复制(更新)Plugin.dll,并且它在组合期间抛出异常:

Unable to load one or more of the requested types. Retrieve the LoaderExceptions for more information

这当然是因为它试图导入的Plugin.dll实现了不同版本的IPlugin,其中属性/方法签名不匹配.虽然在受控和受监控的环境中很容易避免这种情况,但通过简单地避免(duh)插件文件夹中过时的IPlugin实现,我不能依赖于可能遇到传统插件的生产环境中的这种假设.

问题是这个异常有效地破坏了整个Compose操作,并且没有导入导出.我宁愿忽略不匹配的IPlugin实现,因此仍会导入实现正确版本的IPlugin的目录中的其他导出.

有没有办法实现这个目标？我在想几种可能的选择:

• 在调用Compose之前或调用Compose时,要在CompositionContainer上设置一个标志("忽略失败的导入")
• 在<ImportMany()>属性上指定了类似的标志
• 有一种方法可以"挂钩"基于Compose()的迭代过程,并且能够单独处理每个(失败的)导入
• 使用强名称签名以某种方式仅查找实现当前版本的IPlugin的导入

想法？

我试图在64位x86环境中加载在Linux上使用"gcc -m32 test.c -o test.exe"编译的ELF文件.我试图在具有以下核心逻辑(32位ELF)的用户空间ELF加载器中加载该32位文件(test.exe).

问题是调用返回的起始地址会导致分段错误核心转储.这是代码:

void *image_load (char *elf_start, unsigned int size)
{
    Elf32_Ehdr      *hdr    = NULL;
    Elf32_Phdr      *phdr   = NULL;
    unsigned char   *start  = NULL;
    Elf32_Addr      taddr   = 0;
    Elf32_Addr      offset  = 0;
    int i = 0;
    unsigned char *exec = NULL;
    Elf32_Addr      estart = 0;

    hdr = (Elf32_Ehdr *) elf_start;

    if(!is_image_valid(hdr)) {
        printk("image_load:: invalid ELF image\n");
        return 0;
    }

    exec = (unsigned char *)mmap(NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
                      MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);

    if(!exec) { …