| Summary: | Unable to debug dynamic loader when LD_TRACED_LOADED_OBJECTS env var is set. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Carlos O'Donell <codonell> |
| Component: | gdb | Assignee: | Jan Kratochvil <jan.kratochvil> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | gbenson, jan.kratochvil, palves, pmuldoon, sergiodj, tromey |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-22 19:42:53 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Carlos O'Donell
2013-10-22 16:42:48 UTC
Working around this by not setting the env var, breaking in process_envvars in the loader and manually manipulating the mode state. It's not what I'd like to do since it requires touching the internal state of the loader, but this is well contained code at this point. Use exec-wrapper env. You are modifying the shell used to start the inferior, GDB at least expects the shell will behave sane. $ gdb -q /lib64/ld-linux-x86-64.so.2 done. (gdb) set exec-wrapper env LD_TRACE_LOADED_OBJECTS=1 (gdb) b _start Breakpoint 1 at 0x3000001420 (gdb) run /bin/true Starting program: /lib64/ld-linux-x86-64.so.2 /bin/true Breakpoint 1, 0x0000555555555420 in _start () (gdb) c Continuing. linux-vdso.so.1 => (0x00007ffff7ffd000) libc.so.6 => /lib64/libc.so.6 (0x0000003030400000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) [Inferior 1 (process 29183) exited normally] (gdb) Reopening to ask some more questions. (In reply to Jan Kratochvil from comment #2) > Use exec-wrapper env. You are modifying the shell used to start the > inferior, GDB at least expects the shell will behave sane. Talking about a shell is an implementation defined detail for gdb. The result of `help set env' says: "Set environment variable value to give the program." Why does this impact my ability to debug the inferior? I appreciate the use of the exec-wrapper workaround, but it's still a workaround. What expectations does gdb have that aren't being met? As an upstream glibc maintainer I'd be more than happy to work out something where it's *easy* to debug the dynamic loader rather than requiring anything complicated. (In reply to Carlos O'Donell from comment #3) > The result of `help set env' says: > "Set environment variable value to give the program." This is true for normal users. GDB users are not expected to be ld.so developers. > Why does this impact my ability to debug the inferior? + > What expectations does gdb have that aren't being met? Shell compiled into GDB due to its compile-time configuration #define STARTUP_WITH_SHELL 1 failed to start the inferior. When you build your own GDB having this symbol undefined it may work without the env wrapper. > As an upstream glibc maintainer I'd be more than happy to work out something > where it's *easy* to debug the dynamic loader rather than requiring anything > complicated. Before GDB supported PIE it really was not easy to debug ld.so. Using one "set exec-wrapper env" command for debugging something so special like ld.so I do not find anyhow bad. Moreover the reasons are known and it seems correct to me. Leaving the Bug open but I do not plan to work on it myself. (In reply to Jan Kratochvil from comment #4) > (In reply to Carlos O'Donell from comment #3) > > The result of `help set env' says: > > "Set environment variable value to give the program." > > This is true for normal users. GDB users are not expected to be ld.so > developers. The difference is pedantic, we should still strive to make it easy to debug any program including the dynamic loader. > > Why does this impact my ability to debug the inferior? > + > > What expectations does gdb have that aren't being met? > > Shell compiled into GDB due to its compile-time configuration > #define STARTUP_WITH_SHELL 1 > failed to start the inferior. Thanks, I read the code and understand now what STARTUP_WITH_SHELL does and what implications it has for debugging with environment variables that modify the runtime. > When you build your own GDB having this symbol undefined it may work without > the env wrapper. ... and that also has it's own problems. > > As an upstream glibc maintainer I'd be more than happy to work out something > > where it's *easy* to debug the dynamic loader rather than requiring anything > > complicated. > > Before GDB supported PIE it really was not easy to debug ld.so. Using one > "set exec-wrapper env" command for debugging something so special like ld.so > I do not find anyhow bad. Moreover the reasons are known and it seems > correct to me. After reading the code and the features STARTUP_WITH_SHELL enables, I agree with you, even if I wish I didn't need the extra step. I'll document this in the glibc wiki. Thanks for talking it through Jan, I appreciate your time and knowledge. |