移植 c/c++ 时的问题 代码到VxWorks

发布于 2024-07-23 01:17:28 字数 86 浏览 8 评论 0原文

我需要将已经支持 Linux/Mac 的 ac/c++ 代码库移植到 VxWorks。 我对 VxWorks 还很陌生。 您能让我知道可能出现哪些问题吗?

I need to port a c/c++ codebase that already supports Linux/Mac, to VxWorks. I am pretty new to VxWorks. Could you let me know what are the possible issues that could arise?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

小矜持 2024-07-30 01:17:28

我们最近做了相反的转换 - 我们将代码从运行 VxWorks 的 PowerPC 机器移植到运行 Linux 的 Intel 系统。 我不记得在操作系统之间的差异方面遇到过很多障碍。 显然,对操作系统特定 API 的任何调用都必须更改,并且我们没有广泛使用这些函数。

我们最大的问题不是操作系统之间的差异,而是 PowerPC 和 Intel 硬件之间的差异。 PowerPC 是 Big Endian,Intel 是 Little Endian。 我们的软件是用 C 语言编写的,并对字节顺序做了很多假设,这绝对是让它再次顺利工作的噩梦。 实际上有数百个定义位域的结构,需要重新排序才能正常工作。 我们最终在 GCC 中实现了一个#pragma,它在定义时反转了这些位域(#pragmaverse_bitfields)。

We recently did the opposite conversion - we ported code from a PowerPC machine running VxWorks to an Intel system running Linux. I don't remember hitting many snags as far as the differences between the operating systems. Obviously any call to an OS specific API will have to change and we were not making extensive use of these functions.

Our biggest problem was not the difference between the operating systems, but rather the difference between PowerPC and Intel hardware. PowerPC is Big Endian and Intel is Little Endian. Our software is written in C and made many assumptions as to the order of bytes and this was an absolute nightmare to get it working smoothly again. There were literally hundreds of structures that defined bitfields and needed to be re-ordered to work correctly. We ended up implementing a #pragma in GCC that reversed these bitfields at their definition (#pragma reverse_bitfields).

梦言归人 2024-07-30 01:17:28

这在很大程度上取决于您所针对的 VxWorks 版本以及实际的目标处理器本身。 您必须处理的一件事是没有分页内存系统或虚拟内存——您拥有那里的东西。 环境本身比linux系统受到的限制要大得多。 有时,移植应用程序所涉及的工作会一直追溯到体系结构级别,因为资源不像 Linux 中那样不受限制。

其他一些提示:

  • 许可 vxworks,以便您拥有可用的源代码,
  • 在开发周期中尽快使用真实的物理目标; 不要指望模拟器
  • 在必要时准确模拟目标使用 TSR(技术支持请求); 我不知道他们如何构建购买创建股东总回报权的权利,但不要让任何人在这些上便宜

Much depends on which version of VxWorks you're targeting, and the actual target processor itself. One thing you will have to deal with is that there is no paged memory system or virtual memory--you have what's there. The environment itself is far more constrained than a linux system. Sometimes the work involved in porting applications goes all the way back to the architecture level because resources are not as unlimited as they are in linux.

Some other tips:

  • license vxworks such that you have the source code available
  • use a real, physical target as soon as possible in the development cycle; do not count on the simulators accurately emulating the target
  • use TSRs (technical support requests) as necessary; I don't know how they structure the purchase of the right to create TSRs, but don't let anybody cheap out on these
渡你暖光 2024-07-30 01:17:28

根据您运行的处理器的不同,VxWorks 字节顺序、结构打包和内存对齐都可能会出现问题。 上次我使用 VxWorks 时,它支持 pthreads、套接字和互斥层,可以轻松模仿 UNIX 环境。

Depending on what processor you are running with VxWorks endianness, structure packing, and memory alignment could all be issues. The last time I used VxWorks it supported a pthreads, sockets, and mutex layer that mimicked the unix environments easily enough.

最好是你 2024-07-30 01:17:28

如果不了解有关您正在移植的应用程序的更多信息,则很难判断:它使用哪些 Linux 库和 api 调用? 它是独立的,还是依赖大量的 Linux 命令行工具和脚本来完成其工作?

正如 Average 所说,字节顺序可能会给您带来比您预期更多的问题 - 特别是如果您没有做好准备的话。

It's difficult to tell, without knowing more about the application that you're porting: What linux libraries and api calls does it use? Is it self-contained, or does it rely on slews of linux command-line tools and scripts to do its job?

As Average says, endianness can cause you way more problems than you expect - particularly if you're not prepared for it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文