還是昨天的問題，上午和相關的人一起討論了一下嗎，還是隻有一條路可走，爲TM單獨出一個lib，爲他單獨管理共享內存。經過我們的一再“挖掘”，TM的leader也總算是像我們解釋清楚了爲何他有這個特殊的需求：TM的兩個process之間共享一大塊的內存，初始部分是一個結構體，這個結構體裏面含有指針。在進程A裏面指針的值是A的，要想在B能正常解析出這塊內存的內容，就必須使得它在A和B虛擬空間中attach的地址是一樣的。HP是能夠保證的，但是linux上卻沒有這樣的承諾。所以需要我們的庫提供這樣的功能。其實這種共享的方式是不對的，正確的做法應該是使用偏移量。
中午和同事對調了下位置，感覺這邊很失敗，周圍的人都不是同一個組的，並且感覺融入進去很難，沒意思。
下午繼續弄這個問題，一開始不想改變A/B，只是將重新編譯的庫剛在原來庫的前面，這樣應該是能使得他們調用新庫的，但是測試的時候發現了其他的問題，似乎不行。明天有時間仔細測試一下，可能是其他的原因導致的。發現的一個問題還是很多。後來在新庫裏面重新定義了下接口名字，同時改變A/B的調用和編譯依賴，後來也只是勉強跑通了新庫，真正的測試明天才能弄。進展不大，部分原因是測試的過程中沒有做好記錄，搞得後來都弄不清楚沒次失敗時的狀態是什麼了。另外一個是測試新庫的時候搞亂了內存還是什麼東西，使得我們的系統老是起不來，我記得是講共享內存全部刪除了的，但是也沒有時間深究，只是重啓系統了事。這個過程中碰到了一些問題，這裏記下來，日後可以查驗下：
1）庫的引用名字是在編譯的時候定好了的，單純改編譯後的庫文件的名稱並不起作用。比如A用到一個庫libux_v1.sl，ldd查看使用時的庫名稱是libux.0（鏈接），將庫文件改爲libux_v2.sl，重新編譯A以後，它實際上還是引用的libux.0。這個不帶版本號的link是爲了增加系統的靈活性，不同的版本庫都可以使用一個庫的引用名字。因爲我這裏要引用新庫，但是原來的庫還得用，所以我開始以爲將新庫放到和A同一個目錄下就可以了，連鏈接都忘了建（基本功不紮實，好在後來醒悟了）。後來建立了鏈接又不對，因爲我用原來的名字連接到新庫，導致其他的應用都用了我的新庫，直接搞死系統；
2）mmap的效果子進程會繼承。所以在原有庫裏面reserve的pages範圍在A/B依然起作用，導致在A/B裏面要保存的地址開始地址要相應地往上偏移。這個通過配置環境變量可以比較輕鬆搞定；
3）用ldd A可以看到所需要的庫都被找到了，但是我們的系統在起A的時候卻報告無法找到新庫。我檢查了LD_PATH(全名忘了)，發現路徑都在裏面，這個還沒有弄清楚原因，都算是週末的工作吧