Bug in gcc.c for_each_path() (leads to invalid crt0.o selection)?

[Sebastian Huber <sebastian dot huber at embedded-brains dot de>]

Hello,

I noticed that the ARM libgomp is built without TLS support for RTEMS, 
since the thread-local storage detection fails, due to missing symbols 
in the crt0.o. I added the missing symbols to newlib/libc/sys/rtems/crt0.c:

https://sourceware.org/ml/newlib/2016/msg01138.html

However, this still didn't work. The reason is that during GCC build the 
random crt0.o of the prefix is used.

The configure test command line is:

/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc 
-B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc 
-B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/ 
-isystem 
/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/targ-include 
-isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include 
-B/opt/rtems-4.12/arm-rtems4.12/bin/ 
-B/opt/rtems-4.12/arm-rtems4.12/lib/ -isystem 
/opt/rtems-4.12/arm-rtems4.12/include -isystem 
/opt/rtems-4.12/arm-rtems4.12/sys-include  -mthumb -o conftest -g -O2 
conftest.c

GCC searches then in:

Breakpoint 10, file_at_path (path=0x72a960 
"/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/arm-rtems4.12/7.0.0/thumb/", 
data=0x7fffffffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733
2733    {
$70 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}

Breakpoint 10, file_at_path (path=0x72a960 
"/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/thumb/", 
data=0x7fffffffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733
2733    {
$71 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}

Breakpoint 10, file_at_path (path=0x72a960 
"/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/arm-rtems4.12/7.0.0/thumb/", 
data=0x7fffffffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733
2733    {
$72 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}

Breakpoint 10, file_at_path (path=0x72a960 
"/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/thumb/", 
data=0x7fffffffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733
2733    {
$73 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}

Breakpoint 10, file_at_path (path=0x72a960 
"/opt/rtems-4.12/arm-rtems4.12/bin/arm-rtems4.12/7.0.0/thumb/", 
data=0x7fffffffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733
2733    {
$74 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}

Breakpoint 10, file_at_path (path=0x72a960 
"/opt/rtems-4.12/arm-rtems4.12/bin/thumb/", data=0x7fffffffc8c0) at 
/home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733
2733    {
$75 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}

Breakpoint 10, file_at_path (path=0x72a960 
"/opt/rtems-4.12/arm-rtems4.12/lib/arm-rtems4.12/7.0.0/thumb/", 
data=0x7fffffffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733
2733    {
$76 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}

Breakpoint 10, file_at_path (path=0x72a960 
"/opt/rtems-4.12/arm-rtems4.12/lib/thumb/", data=0x7fffffffc8c0) at 
/home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733
2733    {
$77 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}

Since all previous attempts to find the file failed, it picks up 
"/opt/rtems-4.12/arm-rtems4.12/lib/thumb/crt0.o".

We have in the build tree:

find -name crt0.o
[...]
./arm-rtems4.12/thumb/newlib/crt0.o
./arm-rtems4.12/thumb/newlib/libc/crt0.o
./arm-rtems4.12/thumb/newlib/libc/sys/crt0.o
./arm-rtems4.12/thumb/newlib/libc/sys/rtems/crt0.o
[...]

In gcc.c we have:

[...]
/* Call CALLBACK for each path in PATHS, breaking out early if CALLBACK
   returns non-NULL.
   If DO_MULTI is true iterate over the paths twice, first with multilib
   suffix then without, otherwise iterate over the paths once without
   adding a multilib suffix.  When DO_MULTI is true, some attempt is made
   to avoid visiting the same path twice, but we could do better.  For
   instance, /usr/lib/../lib is considered different from /usr/lib.
   At least EXTRA_SPACE chars past the end of the path passed to
   CALLBACK are available for use by the callback.
   CALLBACK_INFO allows extra parameters to be passed to CALLBACK.

   Returns the value returned by CALLBACK.  */

static void *
for_each_path (const struct path_prefix *paths,
	       bool do_multi,
	       size_t extra_space,
	       void *(*callback) (char *, void *),
	       void *callback_info)
[...]

We have

-B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/
-B/opt/rtems-4.12/arm-rtems4.12/lib/

Its not really clear from the documentation how the search order and 
command line order is related.  The documentation doesn't mention 
multilib and multiarch options.

https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html

If we assume that the command line order determines the search order, 
then its not clear why for_each_path() first iterates for all paths with 
the multilib postfix and then without. Shouldn't it iterate over all 
paths and check with/without multilib postfix in each step?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel