This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Assuming types for PC
- From: Pedro Alves <palves at redhat dot com>
- To: gdb at sourceware dot org
- Cc: Mark Kettenis <mark dot kettenis at xs4all dot nl>, macro at codesourcery dot com, brobecker at adacore dot com, lgustavo at codesourcery dot com
- Date: Tue, 11 Jun 2013 11:09:03 +0100
- Subject: Re: Assuming types for PC
- References: <51B5E06A dot 8020807 at codesourcery dot com> <201306101431 dot r5AEVAfb007850 at glazunov dot sibelius dot xs4all dot nl> <51B5E3D4 dot 9010105 at codesourcery dot com> <201306101504 dot r5AF4pJJ010320 at glazunov dot sibelius dot xs4all dot nl> <alpine dot DEB dot 1 dot 10 dot 1306101838360 dot 16287 at tp dot orcam dot me dot uk> <201306101844 dot r5AIi8Ou017730 at glazunov dot sibelius dot xs4all dot nl> <51B6EC1F dot 3020401 at redhat dot com>
On 06/11/2013 10:21 AM, Pedro Alves wrote:
>>> Overall I think the test is too strict. If you think the use of "long
>>> long" is unfortunate for the PC, then an artificial type might be created
>>> internally within GDB specifically for the PC, similarly to what we do
>>> e.g. for IEEE 754 data types and floating-point registers in some cases.
>>
>> An artificial type like that probably is the way to go.
>
> I agree. Something like the GDB equivalent of:
>
> typedef void * ptr64 __attribute ((mode(DI)));
>
> (That worked last time I tried it on x32, probably works on MIPS too.)
>
BTW, this whole issue is really a special case of an ABI register name
colliding with a machine register name. A similar example came up when GDB
was made to expose whole set of x86 general purpose registers. Specifically
the $rsp/$rsp/$sp, where $sp (16-bit) collides with desire to use $sp
to refer to stack pointer. An alternative idea I thrown out back then,
would be to always leave $pc/$sp/$fp as the ABI version of the registers,
and in case the machine has real registers by that name, expose those with
an alternative naming, like e.g., $_pc/$_sp/$_fp. These would have the
machine's full width.
On i686, you'd get:
32-bit pointer $pc, 16-bit integer $ip, 32-bit pointer $eip.
32-bit pointer $sp, 16-bit integer $_sp, 32-bit pointer $esp.
32-bit pointer $fp, 16-bit integer $bp, 32-bit pointer $ebp.
On x32, you'd get:
32-bit pointer $pc, 16-bit integer $ip, 32-bit pointer $eip, 64-bit integer $rip.
32-bit pointer $sp, 16-bit integer $_sp, 32-bit pointer $esp, 64-bit integer $rsp.
32-bit pointer $fp, 16-bit integer $bp, 32-bit pointer $ebp, 64-bit integer $rbp.
On x86_64 (-m64), you'd get
64-bit pointer $pc, 16-bit integer $ip, 32-bit integer $eip, 64-bit pointer $rip.
64-bit pointer $sp, 16-bit integer $_sp, 32-bit integer $esp, 64-bit pointer $rsp.
64-bit pointer $fp, 16-bit integer $bp, 32-bit integer $ebp, 64-bit pointer $rbp.
On MIPS n32, you'd get:
32-bit pointer $pc, 64-bit integer $_pc/$rNN.
32-bit pointer $sp, 64-bit integer $_sp/$rNN.
32-bit pointer $fp, 64-bit integer $_fp/$rNN.
(the _ variants probably would be raw from any arch bit manipulation).
(I'm not really sure which solution I prefer.)
--
Pedro Alves