<output id="qn6qe"></output>

    1. <output id="qn6qe"><tt id="qn6qe"></tt></output>
    2. <strike id="qn6qe"></strike>

      亚洲 日本 欧洲 欧美 视频,日韩中文字幕有码av,一本一道av中文字幕无码,国产线播放免费人成视频播放,人妻少妇偷人无码视频,日夜啪啪一区二区三区,国产尤物精品自在拍视频首页,久热这里只有精品12

      痞子衡嵌入式:一個奇怪的Keil MDK下變量鏈接強制對齊報錯問題(--legacyalign)


        大家好,我是痞子衡,是正經搞技術的痞子。今天痞子衡給大家分享的是一個奇怪的Keil MDK下變量鏈接強制對齊報錯問題

        痞子衡最近一直在參與恩智浦SBL項目(就是一個適用LPC和i.MXRT的完整OTA方案),這個項目近期會和大家見面,項目需要同時支持GCC, IAR, MDK三大開發環境,項目所屬i.MXRT1170工程在GCC和IAR下編譯鏈接一切正常,但是在MDK下出現了鏈接對齊報錯問題,痞子衡花時間研究解決了這個問題,這個問題算是和MDK工具本身緊緊相關,痞子衡覺得挺有意思(其實主要是想吐槽MDK),特分享給大家。

        也許問題和MDK版本有關,在分析問題前,特別交待一下版本信息:

      一、L6244E報錯問題

        讓我們先看一下這是個啥問題,SBL項目源碼引入了usb stack,在usb stack源文件usb_device_ehci.c里有如下名為qh_buffer的bss型變量定義,這個變量實際長度為3KB,我們要求MDK鏈接時將其放在2KB對齊的地址。

      #define USB_DEVICE_CONFIG_EHCI      (2)
      #define USB_DEVICE_CONFIG_ENDPOINTS (8U)
      
      __attribute__((aligned(2048)))
      static uint8_t qh_buffer[(USB_DEVICE_CONFIG_EHCI - 1) * 2048 + USB_DEVICE_CONFIG_ENDPOINTS * 2 * sizeof(usb_device_ehci_qh_struct_t)];
      

        如下是SBL項目的配套MDK鏈接文件(MIMXRT1176xxxxx_cm7_flexspi_nor.scf),工程代碼是XIP執行的。從鏈接文件內容來看,這是一個非常普通的鏈接文件,除了為i.MXRT啟動頭(FDCB、IVT、BootData)做了一些特殊放置外,其余都是常規鏈接語句,沒有再為其他代碼或變量做特殊放置,基本就是讓鏈接器(armlink)自由發揮。

      #define m_flash_config_start           0x30000400
      #define m_flash_config_size            0x00000C00
      
      #define m_ivt_start                    0x30001000
      #define m_ivt_size                     0x00001000
      
      #define m_interrupts_start             0x30002000
      #define m_interrupts_size              0x00000400
      
      #define m_text_start                   0x30002400
      #define m_text_size                    0x00FBDC00
      
      #define m_data_start                   0x20000000
      #define m_data_size                    0x00040000
      
      #define Stack_Size                     0x0400
      #define Heap_Size                      0x0400
      
      LR_m_text m_flash_config_start m_text_start+m_text_size-m_flash_config_start {
        ; 放置FDCB(i.MXRT特色)
        RW_m_config_text m_flash_config_start FIXED m_flash_config_size {
          * (.boot_hdr.conf, +FIRST)
        }
        ; 放置IVT, BootData(i.MXRT特色)
        RW_m_ivt_text m_ivt_start FIXED m_ivt_size {
          * (.boot_hdr.ivt, +FIRST)
          * (.boot_hdr.boot_data)
        }
        ; 放置中斷向量表
        VECTOR_ROM m_interrupts_start FIXED m_interrupts_size {
          * (.isr_vector,+FIRST)
        }
        ; 放置程序代碼
        ER_m_text m_text_start FIXED m_text_size {
          * (InRoot$$Sections)
          .ANY (+RO)
        }
        ; 放置程序變量
        RW_m_data m_data_start m_data_size-Stack_Size-Heap_Size {
          .ANY (+RW +ZI)
          * (RamFunction)
          * (NonCacheable.init)
          * (*NonCacheable)
        }
       ; 放置程序堆、棧
        ARM_LIB_HEAP +0 EMPTY Heap_Size { }
        ARM_LIB_STACK m_data_start+m_data_size EMPTY -Stack_Size { }
      }
      

        編譯工程得到一個如下圖所示奇怪鏈接錯誤,鏈接器說LR_m_text起始地址沒有按2KB對齊。鏈接文件里指定的LR_m_text加載區地址范圍[m_flash_config_start, m_text_start+m_text_size-m_flash_config_start]只是一個最大的RO存儲范圍,雖然m_flash_config_start等于0x30000400,但是這個起始地址是指定用于放置FDCB的,況且本文主角qh_buffer是個bss型變量(初始化值為0,不需在flash里放初值),完全不占用RO區,僅需分配RW區即可,鏈接器因為qh_buffer的對齊需求而對LR_m_text起始地址這么焦慮,實在讓人費解。

      二、嘗試解決報錯問題

      2.1 調整LR_m_text起始地址

        既然鏈接器對LR_m_text起始地址這么焦慮,干脆不讓它焦慮好了,我們直接將起始地址設成0x30000000(FlexSPI映射起始地址),因此鏈接文件修改如下。注:因為幾個i.MXRT啟動頭的段都是固定地址放置的,所以起始地址的改動對他們沒有影響,對其余未指定地址放置的段更沒有影響。

      #define m_flash_start                  0x30000000
      #define m_flash_size                   0x00FC0000
      
      #define m_flash_config_start           0x30000400
      #define m_flash_config_size            0x00000C00
      
      LR_m_text m_flash_start m_flash_size { ;改動在這里!!!
        ; 放置FDCB
        RW_m_config_text m_flash_config_start FIXED m_flash_config_size {
          * (.boot_hdr.conf, +FIRST)
        }
        ; 放置IVT, BootData
        ; 放置中斷向量表
        ; 放置程序代碼
        ; 放置程序變量
        ; 放置程序堆、棧
      }
      

        改完鏈接文件后重新編譯MDK工程,這次沒有鏈接錯誤了,我們打開工程映射文件(sbl.map),找出其中跟qh_buffer相關的內容,可以看到qh_buffer被放置在了0x20004800處,這個地址確實是2KB對齊的,但這是RW區,其實跟我們設定/改動的LR_m_text加載空間沒有任何聯系。

      ==============================================================================
      Image Symbol Table
          Local Symbols
          Symbol Name                              Value     Ov Type        Size  Object(Section)
          qh_buffer                                0x20004800   Data        3072  usb_device_ehci.o(.bss.qh_buffer)
          [Anonymous Symbol]                       0x20004800   Section        0  usb_device_ehci.o(.bss.qh_buffer)
      
      ==============================================================================
      
      Memory Map of the image
        Image Entry point : 0x30002401
        Load Region LR_m_text (Base: 0x30000000, Size: 0x00011800, Max: 0x00fc0000, ABSOLUTE, COMPRESSED[0x00011518])
      
          Execution Region RW_m_data (Exec base: 0x20000000, Load base: 0x30010000, Size: 0x00005ed8, Max: 0x0003f800, ABSOLUTE, COMPRESSED[0x00000800])
      
          Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object
          0x20004800        -       0x00000c00   Zero   RW         2164    .bss.qh_buffer      usb_device_ehci.o
      

      2.2 為鏈接器加--legacyalign選項

        上一節的方法雖然解決了問題,但是解決方案沒有說服力,僅僅是個替代方案。為此痞子衡翻看了MDK官方文檔,找到了如下關于鏈接對齊方面的一些說明文檔:

        默認情況下armlink鏈接器假設執行區和加載區是4字節對齊的,在鏈接分配時需要插入一些填充空間來滿足區內段的特殊對齊需求,鏈接器在處理填充時有兩個策略:

      • 嚴苛策略--no_legacyalign(默認):指示鏈接器插入填充以強制執行區首地址自然對齊,這里的自然對齊是該區域內已知的最大對齊。這個選項可以確保嚴格符合ELF規范。
      • 寬松策略--legacyalign:指示鏈接器按最小化對齊方式來插入填充。

        讀到這里,我們好像找到了一開始報錯的原因,就是默認的--no_legacyalign搗的鬼,鏈接器應該根據LR_m_text區首地址按qh_buffer對齊要求來填充,但實際上鏈接器卻直接撂挑子不干了,報了個錯。那我們就不讓鏈接器為難了,給它個寬松策略:

        這樣改動之后,不需要調整鏈接文件,MDK工程也能正常編譯連接了。再來看映射文件(sbl/map),qh_buffer鏈接地址相比前一個方案發生了變化,從0x20004800移到了0x20004000,但依然滿足2KB對齊的。

      ==============================================================================
      Image Symbol Table
          Local Symbols
          Symbol Name                              Value     Ov Type        Size  Object(Section)
          qh_buffer                                0x20004000   Data        3072  usb_device_ehci.o(.bss.qh_buffer)
          [Anonymous Symbol]                       0x20004000   Section        0  usb_device_ehci.o(.bss.qh_buffer)
      
      ==============================================================================
      
      Memory Map of the image
        Image Entry point : 0x30002401
        Load Region LR_m_text (Base: 0x30000400, Size: 0x00010944, Max: 0x00fbfc00, ABSOLUTE, COMPRESSED[0x00010408])
      
          Execution Region RW_m_data (Exec base: 0x20000000, Load base: 0x3000f944, Size: 0x000056d8, Max: 0x0003f800, ABSOLUTE, COMPRESSED[0x000001ac])
      
          Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object
          0x20004000        -       0x00000c00   Zero   RW         2164    .bss.qh_buffer      usb_device_ehci.o
      

        最后再提一個MDK自相矛盾的地方,我們加了--legacyalign選項后編譯給了個如下警告,說--legacyalign選項不推薦使用。

        然而我們在MDK官方文檔里看到了備注,說的是armlink v6.6版本以上不推薦加--no_legacyalign選項,那痞子衡正在使用的armlink v6.14版本應該是建議使用--legacyalign選項的,但是為何給警告呢?MDK啊,想說愛你不容易!

        至此,一個奇怪的Keil MDK下變量鏈接強制對齊報錯問題痞子衡便介紹完畢了,掌聲在哪里~~~

      歡迎訂閱

      文章會同時發布到我的 博客園主頁CSDN主頁知乎主頁微信公眾號 平臺上。

      微信搜索"痞子衡嵌入式"或者掃描下面二維碼,就可以在手機上第一時間看了哦。

      posted @ 2020-12-01 18:24  痞子衡  閱讀(1917)  評論(0)    收藏  舉報
      主站蜘蛛池模板: 久久精品国产免费观看频道| 亚洲精品色无码AV试看| 久久精品av国产一区二区| xxxxbbbb欧美残疾人| 国产美女永久免费无遮挡| 日韩av日韩av在线| 四虎永久播放地址免费| 成熟了的熟妇毛茸茸| 国产精品美女久久久久久麻豆 | 无码人妻久久久一区二区三区| 亚洲の无码国产の无码步美| 人妻少妇乱子伦精品| 国产午夜美女福利短视频| 日韩av中文字幕有码| 国产成人午夜精品永久免费| 大地资源中文第二页日本| 国产成人高清亚洲综合| 久久综合精品成人一本| 国产成人精品久久综合| 人妻少妇精品无码专区| 丰满人妻一区二区三区无码AV| 国产初高中生粉嫩无套第一次 | 亚洲精品国产精品乱码不| 一区二区三区四区精品视频| 免费人成在线视频无码| 18禁国产一区二区三区| 国产乱妇乱子视频在播放| 成全世界免费高清观看| 好吊视频一区二区三区人妖| 福利一区二区1000| 韩国三级在线 中文字幕 无码| 亚洲综合黄色的在线观看| 成人中文在线| 超碰成人精品一区二区三| 国产亚洲综合欧美视频| 亚洲中文字幕在线二页| 女同精品女同系列在线观看| AV人摸人人人澡人人超碰| 国产在线无码不卡播放| 人妻蜜臀久久av不卡| 亚洲熟女乱色综合一区 |