headers
Grant Grundler | 1 Aug 17:13

Re: [RFC][PATCH] Coding style fix include/asm-parisc/compat_rt_sigframe.h

On Wed, Aug 01, 2007 at 04:55:00PM +0200, Michal Piotrowski wrote:
> Hi,
> 
> Coding style fix

Acked-by: Grant Grundler <grundler <at> parisc-linux.org>

thanks,
grant

> 
> Regards,
> Michal
> 
> --
> LOG
> http://www.stardust.webpages.pl/log/
> 
> Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski <at> gmail.com>
> 
> --- linux-mm-clean/include/asm-parisc/compat_rt_sigframe.h	2007-07-09 01:32:17.000000000 +0200
> +++ linux-mm/include/asm-parisc/compat_rt_sigframe.h	2007-08-01 16:51:57.000000000 +0200
> @@ -1,6 +1,6 @@
> -#include<linux/compat.h>
> -#include<linux/compat_siginfo.h>
> -#include<asm/compat_ucontext.h>
> +#include <linux/compat.h>
> +#include <linux/compat_siginfo.h>
> +#include <asm/compat_ucontext.h>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Soete | 3 Aug 15:16
Picon
Favicon

Re: Some warning: ... cleanup; realy no interest?

Dave, Helge,

> > /CAD/linux-2.6.22-pa/drivers/parisc/dino.c: In function ?dino_bridge_init?:
> > /CAD/linux-2.6.22-pa/drivers/parisc/dino.c:821: warning: format %lx
expects type long unsigned int, but argument 4 has type 
> > resource_size_t
> > /CAD/linux-2.6.22-pa/drivers/parisc/dino.c:821: warning: format %lx
expects type long unsigned int, but argument 5 has type 
> > resource_size_t
> 
> Are you sure you changed line 821?
> 
Ah yes I missed this, sorry?

Ok it seems that [Zz] fix this warning for 32bit kernel but not 64bit one.

For another b2k config, I tried this change:
drivers/parisc/sba_iommu.c:

   1912         printk(KERN_INFO "%s found %s at 0x%zx\n",
   1913                 MODULE_NAME, version, dev->hpa.start);

and to build 32bit kernel there isn't anymore warning:

  gcc -Wp,-MD,drivers/parisc/.sba_iommu.o.d  -nostdinc -isystem
/usr/lib/gcc/hppa-linux-gnu/4.1.3/include -D__KERNEL__ -Iinclude -Iinclude2
-I/CAD/linux-2.6.22-pa/
include -include include/linux/autoconf.h
-I/CAD/linux-2.6.22-pa/drivers/parisc -Idrivers/parisc -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-alias
(Continue reading)

Permalink | Reply | 8 comments |
headers
John David Anglin | 3 Aug 17:16
Picon

Re: Some warning: ... cleanup; realy no interest?

> > > /CAD/linux-2.6.22-pa/drivers/parisc/dino.c: In function ?dino_bridge_init?:
> > > /CAD/linux-2.6.22-pa/drivers/parisc/dino.c:821: warning: format %lx
> expects type long unsigned int, but argument 4 has type 
> > > resource_size_t
> > > /CAD/linux-2.6.22-pa/drivers/parisc/dino.c:821: warning: format %lx
> expects type long unsigned int, but argument 5 has type 
> > > resource_size_t

>From linux/types.h:

#ifdef CONFIG_RESOURCES_64BIT
typedef u64 resource_size_t;
#else
typedef u32 resource_size_t;
#endif

%lx looks right for parisc.  This is ugly but you can kill the warning
by casting arguments 4 and 5 to unsigned long.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 7 comments |
headers
Kyle McMartin | 3 Aug 17:39
Picon

Re: Some warning: ... cleanup; realy no interest?

On Fri, Aug 03, 2007 at 11:16:08AM -0400, John David Anglin wrote:
> > > > /CAD/linux-2.6.22-pa/drivers/parisc/dino.c: In function ?dino_bridge_init?:
> > > > /CAD/linux-2.6.22-pa/drivers/parisc/dino.c:821: warning: format %lx
> > expects type long unsigned int, but argument 4 has type 
> > > > resource_size_t
> > > > /CAD/linux-2.6.22-pa/drivers/parisc/dino.c:821: warning: format %lx
> > expects type long unsigned int, but argument 5 has type 
> > > > resource_size_t
> 
> >From linux/types.h:
> 
> #ifdef CONFIG_RESOURCES_64BIT
> typedef u64 resource_size_t;
> #else
> typedef u32 resource_size_t;
> #endif
> 
> %lx looks right for parisc.  This is ugly but you can kill the warning
> by casting arguments 4 and 5 to unsigned long.
> 

We're "supposed" to use %llx and cast to a ULL, this is because of
CONFIG_RESOURCES_64BIT which is for crap architectures which have
32-bit registers, but the possibility of bigger physical addresses,
(think i386 with 36-bit PAE addressing.)

--Kyle
Permalink | Reply | 6 comments |
headers
Randolph Chung | 3 Aug 19:06

[hppa patch] Fix register definitions for hppa

Should be self-explanatory. We came across this while debugging
TLS-enabled thread debugging on hppa-linux. GDB was not reading 
cr27 (hppa's thread register), so thread-debugging failed quite 
miserably :(

If there are no comments, I shall commit in a couple of days.

thanks,
randolph

2007-08-03  Randolph Chung  <tausq <at> debian.org>

	* hppa-tdep.c (hppa32_cannot_fetch_register)
	(hppa64_cannot_fetch_register): New functions.
	(hppa_gdbarch_init): Set cannot_fetch_register appropriately.
	* hppa-tdep.h (hppa_regnum): Add HPPA_CR26_REGNUM.

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.234
diff -u -p -r1.234 hppa-tdep.c
--- hppa-tdep.c	15 Jun 2007 22:44:55 -0000	1.234
+++ hppa-tdep.c	13 Jul 2007 16:26:29 -0000
@@ -2676,6 +2676,16 @@ hppa32_cannot_store_register (int regnum
 }

 static int
+hppa32_cannot_fetch_register (int regnum)
+{
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 3 Aug 19:11
Gravatar

Re: [hppa patch] Fix register definitions for hppa

On Fri, Aug 03, 2007 at 05:06:46PM +0000, Randolph Chung wrote:
> Should be self-explanatory. We came across this while debugging
> TLS-enabled thread debugging on hppa-linux. GDB was not reading 
> cr27 (hppa's thread register), so thread-debugging failed quite 
> miserably :(
> 
> If there are no comments, I shall commit in a couple of days.

Seems OK to me too.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Carlos O'Donell | 3 Aug 20:32

Re: [hppa patch] Fix register definitions for hppa

On 8/3/07, Randolph Chung <randolph <at> tausq.org> wrote:
> 2007-08-03  Randolph Chung  <tausq <at> debian.org>
>
>         * hppa-tdep.c (hppa32_cannot_fetch_register)
>         (hppa64_cannot_fetch_register): New functions.
>         (hppa_gdbarch_init): Set cannot_fetch_register appropriately.
>         * hppa-tdep.h (hppa_regnum): Add HPPA_CR26_REGNUM.
>
> Index: hppa-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
> retrieving revision 1.234
> diff -u -p -r1.234 hppa-tdep.c
> --- hppa-tdep.c 15 Jun 2007 22:44:55 -0000      1.234
> +++ hppa-tdep.c 13 Jul 2007 16:26:29 -0000
> @@ -2676,6 +2676,16 @@ hppa32_cannot_store_register (int regnum
>  }
>
>  static int
> +hppa32_cannot_fetch_register (int regnum)
> +{
> +  /* cr26 and cr27 are readable (but not writable) from userspace.  */
> +  if (regnum == HPPA_CR26_REGNUM || regnum == HPPA_CR27_REGNUM)
> +    return 0;
> +  else
> +    return hppa32_cannot_store_register (regnum);
> +}
> +

Isn't there a way we can teach gdb that cr27 is writable via this sequence?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randolph Chung | 3 Aug 22:12

Re: [parisc-linux] [hppa patch] Fix register definitions for hppa

> Isn't there a way we can teach gdb that cr27 is writable via this sequence?
> 
> e.g.
> static inline void __set_cr27(struct pthread *cr27)
> {
>   asm ( "ble    0xe0(%%sr2, %%r0)\n\t"
>         "copy   %0, %%r26"
>         : : "r" (cr27) : "r26" );
> }
> 
> At the very least please adjust the comment to say "cr27 is writable via
> a kernel helper function."
> 
> How does gdb read cr27? It must know how to use mfctl?

Remember that gdb is reading the cr27 of the debuggee, not of itself, so
__set_cr27 is irrelevant.

 From the architecture point of view, CR26 and CR27 are only readable
from userspace, so gdb should not enable somebody to set them from
inside gdb.

GDB gets the value of cr26/cr27 the same way it gets the value of other
registers -- via ptrace or the register set returned in a core dump,
etc...

randolph
--

-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlos O'Donell | 4 Aug 18:35

Re: [hppa patch] Fix register definitions for hppa

On 8/3/07, Randolph Chung <randolph <at> tausq.org> wrote:
> Remember that gdb is reading the cr27 of the debuggee, not of itself, so
> __set_cr27 is irrelevant.

Is it usefull to be able to adjust the inferior's thread register?

>  From the architecture point of view, CR26 and CR27 are only readable
> from userspace, so gdb should not enable somebody to set them from
> inside gdb.

Would it be usefull to adjust the thread register when debugging glibc?

Cheers,
Carlos.
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 4 Aug 19:02
Gravatar

Re: [parisc-linux] [hppa patch] Fix register definitions for hppa

On Sat, Aug 04, 2007 at 12:35:26PM -0400, Carlos O'Donell wrote:
> >  From the architecture point of view, CR26 and CR27 are only readable
> > from userspace, so gdb should not enable somebody to set them from
> > inside gdb.
> 
> Would it be usefull to adjust the thread register when debugging glibc?

Not especially.  You can call a glibc function to do so, if you need.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |

Gmane