[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

getcwd replacement + cross compilation

From: Sergio Durigan Junior
Subject: getcwd replacement + cross compilation
Date: Wed, 22 Aug 2018 16:45:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)


A user has recently reported:


This is a bug against GDB, reporting a problem that happens when
cross-compiling it for ARM/AArch64 architectures.  The problem is that,
in this scenario, GDB will use rpl_getcwd instead of the system's
getcwd, and this will cause a problem when you have a non-readable
parent directory.  The reporter provided a nice reproducer:

  I currently don't have easy access to any non-android AArch64, but as
  the problem is due to cross-compilation, not specifically the aarch64
  host, I can reproduce it on ARMv5TE-based Raspbian on Raspberry Pi
  (Model B). Here's how:

  $ cd /tmp
  $ mkdir -p test/a/b/c
  $ cd test/a/b/c
  $ chmod a-r ..
  $ /tmp/gdb # the one compiled without workarounds
  Segmentation fault
  $ chmod a+r ..
  $ /tmp/gdb -q

I'm writing this e-mail because this is likely a gnulib bug, and I'd
like to discuss how to fix it.  After a brief chat with Simon Marchi
(GDB global maintainer) on IRC, it seems that:

1) The detection performed by gnulib's configure scripts is somewhat
wrong/incomplete when cross-compiling, and we should not set
REPLACE_GETCWD in certain situations.

2) Maybe it's really OK/necessary to use the replacement function, but
it is currently buggy because it cannot deal with the scenario described

Note that it's possible to force the use of the system's getcwd by
manually setting gl_cv_func_getcwd_path_max=yes and
gl_cv_func_getcwd_abort_bug=no, but I don't think that's a good way to
fix the problem.

What do you think?


GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible

reply via email to

[Prev in Thread] Current Thread [Next in Thread]