Это ошибка GCC или нет? - PullRequest
       18

Это ошибка GCC или нет?

0 голосов
/ 29 ноября 2018

По сути, я опубликовал несколько вопросов, касающихся моей проблемы.Однако я считаю, что это другой вопрос.

Проще говоря, инструменты Go с определенным набором параметров режима сборки создают файл .o, отличный от PIC (скажем, app.o) и разделяемую библиотеку PIC.скажем, libmain.so.Как видно из названия, libmain.so имеет функцию main внутри.

После этого инструменты Go вызывают gcc, драйвер компилятора, чтобы связать .o и .so для создания исполняемого файла, который не обязательно является PIE.Для упрощения команда компоновщика, которую вызывают инструменты Go, выглядит следующим образом:

$ gcc -o app.x -L. -lmain -Wl,-rpath=$PWD -fuse-ld=gold app.o

Дело в том, что это.По крайней мере три эксперта подтвердили, что Scrt1.o должен использоваться для их связи, так как main находится внутри разделяемой библиотеки PIC.Однако вместо этого gcc вытаскивает crt1.o.

Мой вопрос заключается в том, является ли это ошибкой gcc или ошибкой пользователя.Определенно, если пользователь добавил опцию «-pie» в приведенную выше команду ссылки, вместо этого gcc будет использовать Scrt1.o.Однако пользователи могут утверждать, что, поскольку они могут не захотеть независимого от позиции исполняемого файла, добавление «-pie» может не иметь особого смысла.

Я пытался найти соответствующую информацию в руководствах по gcc, но это не удалось.В этой ситуации пользователь должен указать "-pie"?Или, может ли пользователь сделать исполняемый файл без PIE, чтобы эта проблема представляла собой ошибку gcc?

Для вашего удобства приведем простой пример:

$ cat app.c 
int foo(int x, int y)
{
  volatile int z = x;
  return z + y;
}
$ cat main.c 
extern int foo(int, int);
int main(int argc, char* argv[])
{
  return foo(argc, 4);
}
$ gcc -o app.o -c app.c
$ gcc -o main.o -c -fPIC main.c
$ gcc -o libmain.so -shared main.o
$ gcc -o app.x -L. -lmain -fuse-ld=gold -Wl,-v,-rpath=$PWD app.o
collect2 version 4.8.5 20150623 (Red Hat 4.8.5-36.0.2)
/usr/bin/ld.gold --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -dynamic-linker /lib/ld-linux-aarch64.so.1 -X -o app.x /usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64/crt1.o /usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64/crti.o /usr/lib/gcc/aarch64-redhat-linux/4.8.5/crtbegin.o -L. -L/usr/lib/gcc/aarch64-redhat-linux/4.8.5 -L/usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../.. -lmain -v -rpath=/home/aion1223/workspace/shared app.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/aarch64-redhat-linux/4.8.5/crtend.o /usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64/crtn.o
GNU gold (version 2.27-34.base.0.2.el7) 1.12

1 Ответ

0 голосов
/ 10 января 2019

Эта проблема обсуждалась здесь:

отчет об ошибке gcc

Я думаю, что gcc ясно, что предоставление crt1.o - правильное поведение, так какокончательный исполняемый файл не является пирогом.Кажется, выбрать crt1.o в зависимости от конечного исполняемого файла.

Комментарий Эндрю Пински 18

Согласно комментарию, gcc делает и предназначен для предоставления crt1.o.Таким образом, это не ошибка GCC.Тогда это должна быть проблема золота или глиба.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...