This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Add helper script for glibc debugging
Hi Carlos,
On Thu, 26 Sep 2019, Carlos O'Donell wrote:
>We are getting close!
Nice! :)
>(1) Don't run gdb under the ld.so to be tested.
>
>(2) Provide a way to pass env vars.
>
>If you fix those two things I think the script is basically perfect :-)
>
> [...]
>
>On 9/26/19 10:21 AM, Gabriel F. T. Gomes wrote:
>>
>> +# We need to make sure that gdb is linked against the standalone glibc
>> +# so that it picks up the correct nptl_db/libthread_db.so. So that means
>> +# invoking gdb using the standalone glibc's linker and passing nptl_db
>> +# in the argument to --library-path.
>> +$${BUILD_DIR}/elf/ld.so \
>> + --library-path $(rpath-link):$${BUILD_DIR}/nptl_db \
>> + $${GDB_PATH} -q \
>> + -x $${CMD_FILE} \
>> + -d $${SOURCE_DIR} \
>> + $${BUILD_DIR}/elf/ld.so
>
>This exposes the debugger to all sorts of problems with the bootstrapping
>glibc, like bugs or other issues.
Right. I haven't thought about that before.
>Why are we running gdb undger the new ld.so?
I think it's just because I never questioned what I learned from
<https://sourceware.org/glibc/wiki/Debugging/Loader_Debugging>.
I think I understand it better, now.
>Why not use:
>
>set auto-load safe-path <path>
>set libthread-db-search-path <path>
>
>instead?
You had mentioned it previously (on the URL you shared in your previous
review). Sorry I didn't understand what you meant before, I think I got
it right this time.
>What about environment variables exposed to the test case?
>
>Can we have a consistent way to pass them to the gdb we're about to start
>without exposing them to gdb?
>
>e.g.
>
>set exec-wrapper env 'LD_PRELOAD=libmalloc-extras.so'
OK, I think I also got this right, this time.
I'm posting v3 with these changes.