我有一个小功能,可以在32位架构上将虚拟内存地址转换为物理地址:
uint32_t VIRTBASE;
uint32_t getPhysForVirt(void* virt) {
uint32_t offset = (uint8_t*)virt - VIRTBASE;
return PHYSBASE + offset;
}
在过去的10年里,它的编译和运行没有出现任何问题。
我改变了编译器,为新的体系结构构建了repo(现在首次支持64位)。
编译失败
从' uint8_t*' {aka 'unsigned char*'}到' uint 32 _ t ' { aka ' unsigned int ' }[-fpermissive]的转换无效
现在,我理解了这个消息,但是我不确定要使这个编译没有错误需要什么步骤。
我唯一确定的是,我不想启用-fpermissive。
您正在执行指针算术并将其直接转换为 32 位无符号整数。
在32位架构上,指针也是32位无符号整数,所以这可能是在后台悄悄处理的。
现在,在您的64位架构上,您正在减去两个64位指针并将结果存储在一个32位整数中——因此丢失了一半的地址!
您可能根本不希望该函数返回一个整数,而是一个指向您实际使用的任何数据类型的指针(可能是uint8_t*,因为它在函数本身中显式声明)。
编辑:相反,也许你实际上意味着取消引用virt
并减去其值,而不是做指针算术?如果是这样,则将 *
运算符放在错误的位置。尝试:
uint32_t offset = (uint8_t) *virt - VIRTBASE;
不过,正如另一位评论者所指出的,这会导致取消引用空指针的问题。你必须先把它转换成有意义的东西。
你用错了类型。C语言有一些特殊类型,用于将指针强制转换为整数值。
uintptr_t VIRTBASE;
uintptr_t getPhysForVirt(const void * restrict virt) {
ptrdiff_t offset = (uintptr_t)virt - VIRTBASE;
return PHYSBASE + offset;
}
如果其余的代码是按照这个函数的方式编写的——圣诞节你有很多工作要做。
null 人们如何克服Flyway的新版本不再接受现有SQL迁移的问题。或者,是否有人“放弃”,只是创建一个新的基线,而不是做漫长的升级路径?(或者,从Flyway切换到具有类似优点的另一种工具)
当前很多企业正在采用云原生应用程序架构,这可以帮助其IT转型,成为市场竞争中真正敏捷的力量。 O'Reilly 的报告中定义了云原生应用程序架构的特性,如微服务和十二因素应用程序。 本书中作者Matt Stine还探究了将传统的单体应用和面向服务架构(SOA)应用迁移到云原生架构所需的文化、组织和技术变革。本书中还有一个迁移手册,其中包含将单体应用程序分解为微服务,实施容错模式和执行云原生服务的自
我刚刚收到并阅读了Google Play的时事通讯,其中提到从明年开始,该商店“将要求具有本机库的新应用程序和应用程序更新除了32位版本外还提供64位版本”。 对于那些还没有读过的人来说,它指出: 2019年64位支持需求 Android 5.0 中引入了对 64 位架构的平台支持。如今,超过40%的Android设备上线支持64位,同时仍保持32位兼容性。对于使用本机库的应用,64 位代码通常提
我试图比较Peter Cordes在回答“将CPU寄存器中的所有位设置为1”的问题时提到的方法。 因此,我编写了一个基准测试,将所有13个寄存器设置为除、和之外的所有位1。 代码如下所示<代码>乘以32 nop用于避免DSB和LSD影响。 我测试了他提到的以下方法,以及这里的完整代码 为了使这个问题更简洁,我将使用替换下表中的。 下表显示,从组1到组3,当使用64位寄存器时,每个循环多1个周期。
我必须将普通的C .h文件集成到我的C项目(Qt GUI)中。为此,我必须避免一些带有棘手替换的函数指针。您可以在下面看到的代码段之前在MinGW 5.3.0 C中编译没有任何问题。但是当我尝试使用更多新的编译器(C为7.3.0)时,我收到一个错误“从'int'到'void(void)(void)'的无效转换”,但它仍然编译没有问题与相同的7.3.0 for C。 问:编译器给我的宏表达式错误是
问题内容: 我有一个32位.so二进制库,我必须生成使用它的64位程序。有没有办法包装或转换它,使其可以与64位程序一起使用? 问题答案: 不能。您不能直接链接到64位程序内部的32位代码。 最好的选择是编译一个可以在64位平台上运行的32位(独立)程序(使用ia32),然后使用一种进程间通信的形式从64位程序与其进行通信。