Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

llvm-strip utility strips debuglink sections by default whereas GNU strip does not #57407

Closed
kraj opened this issue Aug 28, 2022 · 9 comments
Closed
Assignees
Labels
good first issue https://github.com/llvm/llvm-project/contribute tools:llvm-objcopy/strip

Comments

@kraj
Copy link
Contributor

kraj commented Aug 28, 2022

I ran into a problem where debug info was not being loaded by gdb. In yocto we split the debug info and keep them separate.
so it turns out to be that when we use llvm-strip for providing STRIP it ends up eating .gnu_debuglink section as well which contains the link to separated out debug info file and hence the debugger can not find the link any more. This is seen with clang-14/clang-15 and trunk too.

Here is a testcase

set -x
#CROSS=x86_64-yoe-linux-
#TC=llvm-
rm -rf a.out*
clang -g -xc /dev/null -ffreestanding -shared -o a.out
${CROSS}${TC}objcopy --version
${CROSS}${TC}objcopy --only-keep-debug a.out a.out.dbg
${CROSS}${TC}objcopy --add-gnu-debuglink=a.out.dbg a.out
#${CROSS}${TC}strip --remove-section=.note -o a.out.stripped a.out
${CROSS}${TC}strip -o a.out.stripped a.out
#${CROSS}${TC}objcopy --strip-debug a.out a.out.stripped
${CROSS}readelf -wk a.out.stripped

bad

TC=llvm- sh build.sh

good

sh build.sh
@kraj
Copy link
Contributor Author

kraj commented Aug 28, 2022

@MaskRay FYI

@llvmbot
Copy link
Collaborator

llvmbot commented Aug 28, 2022

@llvm/issue-subscribers-tools-llvm-objcopy-strip

@kraj
Copy link
Contributor Author

kraj commented Aug 28, 2022

workaround for now is to add --keep-section=.gnu_debuglink explicitly to llvm-strip cmdline. But I think it would be good if it behaved like GNU strip here.

kraj added a commit to YoeDistro/meta-clang that referenced this issue Aug 30, 2022
We need a fix for llvm/llvm-project#57407
before we can re-enable it

Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj added a commit to kraj/meta-clang that referenced this issue Aug 30, 2022
We need a fix for llvm/llvm-project#57407
before we can re-enable it

Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj added a commit to YoeDistro/meta-clang that referenced this issue Jun 16, 2023
There was an issue with older llvm < 15 releases as reported in [1]
but this seems to be fixed now.

[1] llvm/llvm-project#57407

Signed-off-by: Khem Raj <raj.khem@gmail.com>
@Endilll Endilll added good first issue https://github.com/llvm/llvm-project/contribute and removed beginner labels Aug 15, 2023
@llvmbot
Copy link
Collaborator

llvmbot commented Aug 15, 2023

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

  1. Assign the issue to you.
  2. Fix the issue locally.
  3. Run the test suite locally.
    3.1) Remember that the subdirectories under test/ create fine-grained testing targets, so you can
    e.g. use make check-clang-ast to only run Clang's AST tests.
  4. Create a git commit
  5. Run git clang-format HEAD~1 to format your changes.
  6. Submit the patch to Phabricator.
    6.1) Detailed instructions can be found here

For more instructions on how to submit a patch to LLVM, see our documentation.

If you have any further questions about this issue, don't hesitate to ask via a comment on this Github issue.

@llvm/issue-subscribers-good-first-issue

@felixkellenbenz
Copy link
Contributor

Hey is anyone working on this issue? if not could you please assign it to me ?

@felixkellenbenz
Copy link
Contributor

Hey, my approach would be to add the .gnu_debuglink file to KeepSection of the CommonConfig by default. Maybe someone could tell me if that's viable or if I should think of another approach. Thanks!

@jh7370
Copy link
Collaborator

jh7370 commented Nov 27, 2023

Hey, my approach would be to add the .gnu_debuglink file to KeepSection of the CommonConfig by default. Maybe someone could tell me if that's viable or if I should think of another approach. Thanks!

I suspect this functionality wants to be specific to the ELF file format, so adding it to CommonConfig wouldn't be the right approach. Some questions to answer:

  1. Should this impact llvm-objcopy as well as llvm-strip (I suspect it should)?
  2. Is the section considered a "debug" section? In other words, if you used the --strip-debug option, would it be removed by GNU strip or objcopy?

If the answer to both questions is yes, then it probably makes sense to add the section name to the list of section names specified in isDebugSection in ELFObjcopy.cpp (see

return StringRef(Sec.Name).startswith(".debug") || Sec.Name == ".gdb_index";
).

@felixkellenbenz
Copy link
Contributor

Thanks for your answer, I will look into this as soon as possible.

jh7370 pushed a commit that referenced this issue Jan 24, 2024
…-all (#78919)

This fixes the issue mentioned here:
#57407
It prevents `llvm-objcopy` from removing the `.gnu _debuglink` section
when used with the `--strip-all` flag. Since `--strip-all` is the
default of `llvm-strip` the patch also prevents `llvm-strip` from
removing the `.gnu_debuglink` section.
@felixkellenbenz
Copy link
Contributor

Hey,

the issue was fixed by #78919, could someone close it ?

wanghao75 pushed a commit to openeuler-mirror/llvm-project that referenced this issue Apr 13, 2024
…-all (#78919)

This fixes the issue mentioned here:
llvm/llvm-project#57407
It prevents `llvm-objcopy` from removing the `.gnu _debuglink` section
when used with the `--strip-all` flag. Since `--strip-all` is the
default of `llvm-strip` the patch also prevents `llvm-strip` from
removing the `.gnu_debuglink` section.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue https://github.com/llvm/llvm-project/contribute tools:llvm-objcopy/strip
Projects
None yet
Development

No branches or pull requests

7 participants