This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 05/08/2015 11:40 AM, Pedro Alves wrote:
On 05/07/2015 03:01 PM, Luis Machado wrote:On 05/07/2015 07:44 AM, Luis Machado wrote:On 05/07/2015 06:05 AM, Yao Qi wrote:Luis Machado <lgustavo@codesourcery.com> writes:-# Get the inferior's PID. -set infpid "" gdb_test_multiple "info inferiors" "getting inferior pid" { - -re "process \($decimal\).*\r\n$gdb_prompt $" { - set infpid $expect_out(1,string) + -re "process $decimal.*\r\n$gdb_prompt $" { } -re "Remote target.*$gdb_prompt $" { # If the target does not provide PID information (like usermode QEMU),This "If the target does not provide PID information" check sounds odd now. Do we still need it?If we're not dealing with PID's, i don't think so.At the very start, I removed this block, but I recall that this block is used as a guard for usermode QEMU which doesn't provide PID information. With this patch applied, we'll access /proc/self/coredump_filter, but I am afraid it doesn't work as expected on usermode QEMU, because usermode QEMU just intercepts few /proc accesses and pass most of them through the host linux. Accessing /proc/QEMU_PID/coredump_filter isn't what we want in this test, so I think it's better to skip the test for usermode QEMU. Of course, I don't mind removing this block. Luis, could you try this patch and remove this block, see whether it causes fails on usermode QEMU?Yeah, that sounds problematic. I'll give it a try and will let you know.Removing that conditional block i get 14 FAIL's, so it doesn't look like this test is suited for usermode QEMU.But what does gdb.log show? With usermode QEMU, the program and qemu are the same process, thus have the same PID. I just tried loading up the test's probably (manually compiled) under F20's qemu-arm, generating a core with gcore, and then loading the core back into gdb, which worked. I didn't test beyond that as I don't have a usermode qemu board file handy (it'd be nice to have one in testsuite/boards/). I'm not immediately seeing the fundamental reason this shouldn't have worked, and we may be hiding a bug instead.
I'll have it reproduced again and will inspect the log. I recall seeing nonsense and random PC addresses that didn't point to proper symbols.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |