Почему компилятор sun C изменяет имена символов при компиляции с отладочной информацией?

#c #compiler-construction #solaris #symbols #sun

#c #компилятор-конструкция #solaris #символы #Солнце

Вопрос:

У меня есть этот исходный файл:

 // ConstPointer.cpp
const short * const const_short_p_const = 0;
const short * const_short_p = 0;
  

и скомпилировал его с отладочной информацией и без нее (компилятор SUN C 5.10):

 # CC ConstPointer.cpp -c -o ConstPointer.o
# CC -g ConstPointer.cpp -c -o ConstPointer-debug.o
  

Вот имена символов объектного файла без информации об отладке:

 # nm -C ConstPointer.o


ConstPointer.o:

[Index]   Value      Size    Type  Bind  Other Shndx   Name

[2]     |         0|       0|SECT |LOCL |0    |10     |
[3]     |         0|       0|SECT |LOCL |0    |9      |
[4]     |         0|       0|OBJT |LOCL |0    |6      |Bbss.bss
[1]     |         0|       0|FILE |LOCL |0    |ABS    |ConstPointer.cpp
[5]     |         0|       0|OBJT |LOCL |0    |3      |Ddata.data
[6]     |         0|       0|OBJT |LOCL |0    |5      |Dpicdata.picdata
[7]     |         0|       0|OBJT |LOCL |0    |4      |Drodata.rodata
[9]     |         4|       4|OBJT |GLOB |0    |3      |const_short_p
[8]     |         0|       4|OBJT |LOCL |0    |3      |const_short_p_const
  

Вот имена символов объектного файла с отладочной информацией:

 # nm -C ConstPointer-debug.o


ConstPointer-debug.o:

[Index]   Value      Size    Type  Bind  Other Shndx   Name

[4]     |         0|       0|SECT |LOCL |0    |9      |
[2]     |         0|       0|SECT |LOCL |0    |8      |
[3]     |         0|       0|SECT |LOCL |0    |10     |
[10]    |         0|       4|OBJT |GLOB |0    |3      |$XAHMCqApZlqO37H.const_short_p_const
[5]     |         0|       0|NOTY |LOCL |0    |6      |Bbss.bss
[1]     |         0|       0|FILE |LOCL |0    |ABS    |ConstPointer.cpp
[6]     |         0|       0|NOTY |LOCL |0    |3      |Ddata.data
[7]     |         0|       0|NOTY |LOCL |0    |5      |Dpicdata.picdata
[8]     |         0|       0|NOTY |LOCL |0    |4      |Drodata.rodata
[9]     |         4|       4|OBJT |GLOB |0    |3      |const_short_p
  

Почему переменная const_short_p_const имеет другое имя символа? g не изменяет его при компиляции с отладочной информацией. Для меня это похоже на ошибку компилятора. Что вы думаете? Второй const (постоянный указатель) приводит к этому.

РЕДАКТИРОВАТЬ комментарий Дрю Холла: например, у вас есть два файла:

 // ConstPointer.cpp
const short * const const_short_p_const = 0;

void foo();

int main(int argc, const char *argv[]) {
  foo();
  return 0;
}
  

и

 // ConstPointer2.cpp
extern const short * const const_short_p_const;

void foo() {
  short x = *const_short_p_const;
}
  

Компиляция в порядке:

 # CC ConstPointer2.cpp -g -c -o ConstPointer2.o
# CC ConstPointer.cpp -g -c -o ConstPointer.o      
  

но связывание не работает, потому что символы отличаются! Имя символа в ConstPointer2.o есть const_short_p_const , но имя символа в ConstPointer.o есть $XAHMCqApZlqO37H.const_short_p_const .

 # CC ConstPointer.o ConstPointer2.o -o ConstPointer
Undefined                       first referenced
 symbol                             in file
const_short_p_const                 ConstPointer2.o
  

Комментарии:

1. Это чисто деталь реализации — почему вас интересуют сгенерированные имена символов?

Ответ №1:

Может быть, это связано с тем фактом, что глобальная const переменная неявно присутствует static в C ?

Комментарии:

1. Конечно. Если вы посмотрите на вывод, который он опубликовал, без информации об отладке привязка локальная; с ней привязка глобальная. (Я подозреваю, что мотивация здесь заключается в том, что после создания ссылки все локальные символы исчезают.) По сути, с отладочными символами Sun CC работает static более или менее так, как если бы они находились в анонимном пространстве имен.

2. Да, в C глобальные переменные const неявно статичны, если вы их явно не объявляете extern . Это позволяет скомпилировать и связать приведенный выше пример с двумя файлами!