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]

Re: [PATCH v5] Add negative repeat count to 'x' command


On 08/16/2016 03:03 PM, Thomas Preudhomme wrote:
> 
>>
>> Wondering whether gdb is actually trying to read from 0xfffffffffffffffd,
>> and that failing somewhere.  The address print routine (paddress) trims
>> the upper 32-bits of CORE_ADDR when debugging a 32-bit target.
>>
>> But probably this just means that that physical address really
>> does not exist on the emulated system, and so qemu's stub returns
>> error when gdb tries to read off of it?
> 
> Yes, I believe that's the case. For some reason reading from 0 works but
> not from the end of the address space. Why not use a multiple regex
> matching and
> make the test UNSUPPORTED with a new regex on this error message?
> 
> This is just a suggestion, I am not very familiar with how GDB deals
> with this
> kind of issue generally but have noticed testcases with several -re patterns.
> 

First I think we should assess whether the behavior is correct or
whether there's a qemu or gdb bug.  If it's a gdb bug, we should fix
it, of course.  If it's a qemu bug, we should report it and maybe XFAIL
it.  If it's not a bug but a qemu personality quirk, then we can make
the tests cope, somehow.

I still wonder why does the read from 0 work at all.  I've tried
reproducing this, using x86_64 Fedora 23's stock qemu-arm:

$ qemu-arm -version
qemu-arm version 2.4.1 (qemu-2.4.1-11.fc23), Copyright (c) 2003-2008 Fabrice Bellard

... but couldn't.  Here's what I get instead:

Terminal 1:

 $ cat crash.c 
 int main ()
 {
   volatile int *null = 0; 

   return *null;
 }

 $ arm-linux-gnueabi -static crash.c

 $ qemu-arm -g 9999 a.out

Terminal 2:

 $ gdb a.out -ex "tar rem :9999"

 (gdb) x 0
 Sending packet: $m0,4#fd...Ack
 Packet received: E14
 0x0:    Cannot access memory at address 0x0

IIRC, arm's exception vector is at 0 and that that's
where execution starts.  But that shouldn't be applicable
to mmu userspace programs?

I wonder what's different between our environments.

Note: I had to use -static, because of:

 $ qemu-arm -g 9999  ./crash.arm 
 /lib/ld-linux.so.3: No such file or directory

I suppose I would need to point qemu at an arm sysroot,
somehow to get past that.

Is there a dejagnu board file somewhere handy one could steal
in order to run tests against qemu-user ?

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]