Question

摘要

我正在使用最新版本的Sourcery CodeBench Lite工具链（GCC arm-none-eabi 4.7.2）将ST的USB OTG库移植到自定义STM32F4板上。

当我用-O0编译代码时，程序运行正常。当我用-O1或-O2编译时它失败了。当我说失败时，它就会停止。没有硬故障，没有（好吧，显然它有什么东西在做但我没有用于调试和发现的模拟器，我很抱歉。我的硬故障处理程序没有被调用）。

详情

我正在尝试调用以下函数...

void USBD_Init(USB_OTG_CORE_HANDLE *pdev,
           USB_OTG_CORE_ID_TypeDef coreID, 
           USBD_DEVICE *pDevice,                  
           USBD_Class_cb_TypeDef *class_cb, 
           USBD_Usr_cb_TypeDef *usr_cb);

...但它似乎没有进入函数体。（这是“砸碎”的症状吗？）

传递给此函数的结构具有以下定义：

typedef struct USB_OTG_handle
{
  USB_OTG_CORE_CFGS    cfg;
  USB_OTG_CORE_REGS    regs;
  DCD_DEV     dev;
}
USB_OTG_CORE_HANDLE , *PUSB_OTG_CORE_HANDLE;

typedef enum
{
  USB_OTG_HS_CORE_ID = 0,
  USB_OTG_FS_CORE_ID = 1
}USB_OTG_CORE_ID_TypeDef;

typedef struct _Device_TypeDef
{
  uint8_t  *(*GetDeviceDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetLangIDStrDescriptor)( uint8_t speed , uint16_t *length); 
  uint8_t  *(*GetManufacturerStrDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetProductStrDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetSerialStrDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetConfigurationStrDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetInterfaceStrDescriptor)( uint8_t speed , uint16_t *length);   
} USBD_DEVICE, *pUSBD_DEVICE;

typedef struct _Device_cb
{
  uint8_t  (*Init)         (void *pdev , uint8_t cfgidx);
  uint8_t  (*DeInit)       (void *pdev , uint8_t cfgidx);
 /* Control Endpoints*/
  uint8_t  (*Setup)        (void *pdev , USB_SETUP_REQ  *req);  
  uint8_t  (*EP0_TxSent)   (void *pdev );    
  uint8_t  (*EP0_RxReady)  (void *pdev );  
  /* Class Specific Endpoints*/
  uint8_t  (*DataIn)       (void *pdev , uint8_t epnum);   
  uint8_t  (*DataOut)      (void *pdev , uint8_t epnum); 
  uint8_t  (*SOF)          (void *pdev); 
  uint8_t  (*IsoINIncomplete)  (void *pdev); 
  uint8_t  (*IsoOUTIncomplete)  (void *pdev);   
  uint8_t  *(*GetConfigDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetUsrStrDescriptor)( uint8_t speed ,uint8_t index,  uint16_t *length);   

} USBD_Class_cb_TypeDef;

typedef struct _USBD_USR_PROP
{
  void (*Init)(void);   
  void (*DeviceReset)(uint8_t speed); 
  void (*DeviceConfigured)(void);
  void (*DeviceSuspended)(void);
  void (*DeviceResumed)(void);  

  void (*DeviceConnected)(void);  
  void (*DeviceDisconnected)(void);    

}
USBD_Usr_cb_TypeDef;

我试图包含与此问题相关的所有源代码。如果您想查看完整的源代码，可以在此处下载：http://www.st.com/st-web-ui/static/active/en/st_prod_software_internet/resource/technical/software/firmware/stm32_f105-07_f2_f4_usb-host-device_lib.zip

尝试的解决方案

我尝试使用#pragma GCC optimize ("O0")，__attribute__((optimize("O0")))，并将某些定义声明为volatile，但没有任何效果。我宁愿修改代码，以使它与优化器完美匹配。

问题

如何修改此代码以使其与GCC的优化器配合使用？

Answer 1

您展示的代码似乎没有任何问题，因此这个答案会更加通用。

“靠近硬件”代码的典型错误是什么，它们在未经优化的情况下正常工作，并且在优化级别较高时失败了？

考虑-O0和-O1/-O2之间的差异：优化策略是 - 其中 - 循环展开（似乎并不危险），尝试尽可能长地保存寄存器中的值，死代码消除和指令重新排序。

改进的寄存器使用通常会导致更高优化级别的问题，如果可以随时更改的硬件寄存器未正确声明volatile（请参阅上面的PokyBrain评论）。优化的代码将尝试尽可能长地保存寄存器中的值，从而导致程序无法注意到硬件方面的更改。 确保正确声明硬件注册volatile

如果您需要读取硬件寄存器以对编译器不知道的硬件产生任何影响并且不对您刚刚读取的值执行任何操作，则消除死代码可能会导致问题。如果您没有正确地声明用于读访问void的变量，那么这些硬件访问可能会被优化掉（但编译器应该发出警告）。 确保将虚拟读取转换为(void)

指令重新排序：如果您需要以特定顺序访问不同的硬件寄存器以产生所需的结果，并且如果您通过其他方式无关的指针来执行此操作，编译器可以自由地重新排序生成的指令，因为它认为合适（即使如果硬件寄存器正确声明volatile）。您需要在代码中隐藏内存障碍，以强制执行所需的访问顺序（__asm__ __volatile__(::: "memory");）。 确保在需要时添加内存屏障。

尽管不太可能，但您可能仍然遇到编译器错误。优化并不是一件容易的事，特别是当它接近硬件时。可能值得一看gcc bug数据库。

如果所有这些都无济于事，那么有时候你无法避免深入研究生成的汇编程序代码，以确保它能够执行它应该做的事情。

GCC 4.7.2优化问题

1 个答案: