小编Jed*_*Jed的帖子

我使用CEDET(最新的CVS)和几个中等规模的项目(每个几百kLOC,主要是C,但有些C++),有时会遇到长时间停顿,系统几秒钟内完全没有响应.更少见的是,它完全旋转失控,我必须进行混搭C-g并尝试移动光标或切换到不同的缓冲区以获得控制权.

我使用GNU Global为我使用的项目创建标签,但这有时仍然很慢,特别是对于semantic-symref-symbol,有些跳转似乎需要解析大量的头文件和源文件.在某些情况下semantic-ia-fast-jump,semantic-ia--fast-jump-helper: Tag SomeFunction has no buffer information即使gtags-find-tag发现它(在同一个项目中),也可能在过时的位置发现错误; 这可能是一个临时的错误,通常semantic-ia-fast-jump是可靠的.

我很感激有关如何做的任何建议

• 节流CEDET而不会失去所有的语义分析.
• 找出导致CEDET失控的原因,以便我可以修复我的项目定义或提交错误报告.
• 确定某些语义分析失败的原因.
• 获取语​​义来缓存更多信息以使其更具响应性,我有很多内存,我想使用它.
• 管理不同位置(包括系统目录)中的多个项目的GNU Global(创建并保持最新).
• 管理我已配置的项目之间的依赖关系ede-cpp-root-project.
• 管理具有多个构建配置的项目,每个构建配置都有自己的"config.h"和构建目录.

文章http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html中有一些提示,我正在寻找除该文章之外的任何内容.

C99规范第6.7.3.8段规定

如果数组类型的规范包括任何类型限定符,则元素类型是合格的,而不是数组类型.如果函数类型的规范包括任何类型的限定符,则行为未定义.

在基本原理(逻辑页面87,物理页面94)中,给出了将平面指针转换为(可变长度)数组指针的示例.

void g(double *ap, int n)
{
    double (*a)[n] = (double (*)[n]) ap;
    /* ... */ a[1][2] /* ... */
}

当然,如果数组ap未在函数内修改,则应将其标记为const,但是应该标记为

void g(const double *ap, int n)
{
    const double (*a)[n] = (const double (*)[n]) ap;
    /* ... */
}

不保留const限定符,因为(每6.7.3.8)它适用于目标的元素而不是目标本身,它具有数组类型double[n].这意味着如果给出适当的标志(-Wcast-qual对于GCC),编译器会正确地抱怨.无法const用C 表示数组类型,但此强制转换非常有用且"正确".该-Wcast-qual标志对于识别数组参数的误用非常有用,但误报不鼓励使用它.请注意,索引a[i][j]更具可读性,并且对于许多编译器而言,生成更好的机器代码,ap[i*n+j]因为前者允许通过较少的分析从内循环中提升某些整数运算.

编译器是否应将此视为特殊情况,有效地将限定符从元素提升到数组类型以确定给定的强制转换是否删除限定符或是否应修改规范？没有为数组类型定义赋值,因此限定符总是应用于数组类型而不仅仅是元素,这与6.7.3.8形成鲜明对比？

使用普通功能,可以编写

extern "C" int Frotz(int);  // in a header

int Frotz(int x) { return x; }

但是,对于函数指针,这似乎在编译器之间不一致地实现.

extern "C" int Klutz(int (*)(int), int);

int Klutz(int (*fptr)(int), int x) { return (*fptr)(x); }

在声明中,论点也是extern "C".在定义中,大多数编译器似乎满足这些功能,使Klutz的extern "C"功能.但是,Sun和Cray编译器会将这些函数解释为不同,从而产生过载int Klutz(int (*fptr)(int), int x),从而产生链接时错误.

虽然C++ 98和C++ 11的7.5.5节保证了解释Frotz,但我无法判断标准是否extern "C"在检查重载之前或之后是否应该进行匹配时是不明确的.

Klutz上面应该生成一个受损的(C++)符号或extern "C"符号吗？

编辑1

我可以使用typedef消除函数指针的歧义,使其具有C或C++ ABI,但我感兴趣的是这里的代码(a)是否定义Klutz了C++链接,(b)将其定义为具有C链接,或者(c)根据标准是模糊的,因此编译器可以自由选择如何解释它.

编辑2

这似乎是一个已知问题,至少是那些具有可搜索错误跟踪器的编译器.在我的测试中,GCC,Clang,Intel,MSVC,IBM XL,PathScale,PGI和Open64都无法区分除语言链接之外相同的功能类型,如标准明确要求的那样(参见7.5.1引用的部分)接受的答案).修复此问题会破坏大量现有代码并需要进行ABI更改.我不知道任何编译器实际上使用不同的C语言与C++语言链接的调用约定.

• 海湾合作委员会的错误:"找到要求从下一个标准中删除此功能的理由是相关的;-)"......"我们甚至可以决定官方的WONTFIX."

• Clang bug:"我害怕实际执行这条规则,因为正确地执行它意味着将语言链接作为规范类型的一部分,这将打破大量代码."

我想拦截dlopen()内部发生的所有文件系统访问.起初,它似乎LD_PRELOAD或-Wl,-wrap,将是可行的解决方案,但由于某些技术原因我无法使它们工作:

• ld.so已经在处理LD_PRELOAD时映射了自己的符号.拦截初始加载对我来说并不重要,但此时_dl_*工作者功能已得到解决,因此未来的调用将通过它们.我认为LD_PRELOAD为时已晚.

• 以某种方式malloc绕过上面的问题,因为malloc()ld.so 的内部没有功能free(),它只是调用memset().

• 文件系统工作者的功能,例如__libc_read(),包含在内ld.so是静态的,所以我不能用它来拦截它们-Wl,-wrap,__libc_read.

这可能意味着我需要ld.so直接从源代码构建自己的代码而不是将其链接到包装器中.我们面临的挑战有两个libc,并rtld-libc从相同的源代码构建.我知道宏IS_IN_rtld是在构建时定义的rtld-libc,但是如何保证在导出公共接口函数时只有一个静态数据结构副本？(这是一个glibc构建系统问题,但我没有找到这些细节的文档.)

有没有更好的方法进入dlopen()？

注意:我不能使用特定于Linux的解决方案,FUSE因为这是针对不支持此类事情的最小"计算节点"内核.

假设我有一个库Common,可以使用独立的,并且所使用的项目P1和P2,因此,树我想要的样子

/Common/.git
        ...
/P1/.git
    .gitmodules  # points to remote server
    Common/
    ...
/P2/.git
    .gitmodules  # points to remote server
    Common/
    ...

当我进行更改时/Common,我希望能够在提交之前P1和P2之前测试它.使用通常的git submodule命令集,我将不得不提交/Common,推送到远程,然后从两个/P1/Common和/P2/Common.如果提交中断了某些内容,则无法修改,因为已经发布了错误的更改.或者,我可以git remote add quicktest /Common在/P?/Common不触摸远程服务器的情况下拉动.但是这有很多不一致的机会,并且删除破坏的提交是很脏的,/P?/Common以便可以修改它们/Common.

我宁愿认为,在开发过程中,从工作树/Common被使用P1和P2,但我不能让/P1/Common一个符号链接/Common,因为git submodule识别符号链接从目录不同.大多数文件系统不允许使用硬链接目录.我可以使用硬链接所有文件

rm -rf /P1/Common
cp -rl /Common /P1/Common

/Common在添加新文件之前效果很好,在这种情况下需要重复此过程.两者都有优雅的方式吗？

1. 继续git …