Keith Owens <[EMAIL PROTECTED]> writes:
>
> Would people prefer the C/ASM filename in BUG() messages instead of the
> include header? If so I will add it to my todo list for the makefile
> rewrite. Of course you can still use __FILE__ and __LINE_ if you
> really want to report the error
Keith Owens [EMAIL PROTECTED] writes:
Would people prefer the C/ASM filename in BUG() messages instead of the
include header? If so I will add it to my todo list for the makefile
rewrite. Of course you can still use __FILE__ and __LINE_ if you
really want to report the error against the
On Sun, 18 Feb 2001 12:33:35 +1100,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>__BASE_FILE__ does this. It expands to the thing which you
>typed on the `gcc' command line.
>
>bix:/home/morton> ./a.out
>3 at a.c
>3 at a.c
But __LINE__ is wrong. Forget what I said about __C_FILE__ and
"J . A . Magallon" wrote:
>
> On 02.18 Andrew Morton wrote:
> >
> > __BASE_FILE__ does this. It expands to the thing which you
> > typed on the `gcc' command line.
> >
> ..
> > 3 at a.c
> > 3 at a.c
>
> I also thought that, but look at the line numbers...wrong and repeated.
Sure. There's no
On 02.18 Andrew Morton wrote:
>
> __BASE_FILE__ does this. It expands to the thing which you
> typed on the `gcc' command line.
>
..
> 3 at a.c
> 3 at a.c
I also thought that, but look at the line numbers...wrong and repeated.
--
J.A. Magallon
Keith Owens wrote:
>
> But
>
> a.h
> static inline void hello(void) { printf("%d at %s\n",__LINE__,__FILE__); }
>
> a.c
> #include
> #include "a.h"
>
> int main()
> {
> hello();
> hello();
> return 0;
> }
>
> # ./a
> 1 at a.h
> 1 at a.h
>
__BASE_FILE__ does this. It
On Sun, 18 Feb 2001 01:33:53 +0100,
"J . A . Magallon" <[EMAIL PROTECTED]> wrote:
>Try this:
>a.h:
>#define hello printf("%d at %s\n",__LINE__,__FILE__)
>
>a.c:
>#include
>#include "a.h"
>
>int main()
>{
>hello;
>hello;
>return 0;
>}
>
>werewolf:~/ko> gcc a.c -o a
>werewolf:~/ko> a
On 02.18 Keith Owens wrote:
>
> __C_FILE__ and __C_LINE__ refer to the .c or .s file that included the
> header, so you get the exact location of the failing code instead of
> the name and line number of a common header which is used all over the
> place. __C_FILE__ would be replaced with the
On Sat, 17 Feb 2001 13:15:42 + (GMT),
Hugh Dickins <[EMAIL PROTECTED]> wrote:
>On Sat, 17 Feb 2001, Paul Gortmaker wrote:
>> Anyway this small patch makes sure there is only one "kernel BUG..." string,
>> and dumps __FILE__ in favour of an address value since System.map data is
>> needed to
On 02.17 Paul Gortmaker wrote:
> I was poking around in a vmlinux the other day and was surprised at the
> amount of repetitive crap text that was in there. For example, try:
>
> strings vmlinux|grep $PWD|wc -c
>
> which gets some 70KB in my case - depends on strlen($PWD) obviously. The
>
On 02.17 J . A . Magallon wrote:
> #if 1
> extern void *__io_virt_debug(unsigned long x, const char *file, int line);
> extern unsigned long __io_phys_debug(unsigned long x, const char *file, int
> li
> ne);
> #define __io_virt(x) __io_virt_debug((unsigned long)(x), __FILE__, __LINE__)
>
On 02.17 Hugh Dickins wrote:
> On Sat, 17 Feb 2001, Paul Gortmaker wrote:
> > I was poking around in a vmlinux the other day and was surprised at the
> > amount of repetitive crap text that was in there. For example, try:
> >
> > strings vmlinux|grep $PWD|wc -c
> >
If you try
strings
On Sat, 17 Feb 2001, Paul Gortmaker wrote:
> I was poking around in a vmlinux the other day and was surprised at the
> amount of repetitive crap text that was in there. For example, try:
>
> strings vmlinux|grep $PWD|wc -c
>
> which gets some 70KB in my case - depends on strlen($PWD)
On Sat, 17 Feb 2001 around 13:26:52 +0100, Manfred Spraul wrote:
> Paul Gortmaker wrote:
> >
> > Anyway this small patch makes sure there is only one "kernel BUG..." string,
> > and dumps __FILE__ in favour of an address value since System.map data is
> > needed to make full use of the BUG()
Paul Gortmaker wrote:
>
> Anyway this small patch makes sure there is only one "kernel BUG..." string,
> and dumps __FILE__ in favour of an address value since System.map data is
> needed to make full use of the BUG() dump anyways. The memory stats of two
> otherwise identical kernels:
>
I was poking around in a vmlinux the other day and was surprised at the
amount of repetitive crap text that was in there. For example, try:
strings vmlinux|grep $PWD|wc -c
which gets some 70KB in my case - depends on strlen($PWD) obviously. The
culprit is BUG() in a static inline that is in
I was poking around in a vmlinux the other day and was surprised at the
amount of repetitive crap text that was in there. For example, try:
strings vmlinux|grep $PWD|wc -c
which gets some 70KB in my case - depends on strlen($PWD) obviously. The
culprit is BUG() in a static inline that is in
Paul Gortmaker wrote:
Anyway this small patch makes sure there is only one "kernel BUG..." string,
and dumps __FILE__ in favour of an address value since System.map data is
needed to make full use of the BUG() dump anyways. The memory stats of two
otherwise identical kernels:
Shouldn't
On Sat, 17 Feb 2001 around 13:26:52 +0100, Manfred Spraul wrote:
Paul Gortmaker wrote:
Anyway this small patch makes sure there is only one "kernel BUG..." string,
and dumps __FILE__ in favour of an address value since System.map data is
needed to make full use of the BUG() dump
On Sat, 17 Feb 2001, Paul Gortmaker wrote:
I was poking around in a vmlinux the other day and was surprised at the
amount of repetitive crap text that was in there. For example, try:
strings vmlinux|grep $PWD|wc -c
which gets some 70KB in my case - depends on strlen($PWD) obviously.
On 02.17 Hugh Dickins wrote:
On Sat, 17 Feb 2001, Paul Gortmaker wrote:
I was poking around in a vmlinux the other day and was surprised at the
amount of repetitive crap text that was in there. For example, try:
strings vmlinux|grep $PWD|wc -c
If you try
strings vmlinux|grep /usr
On 02.17 J . A . Magallon wrote:
#if 1
extern void *__io_virt_debug(unsigned long x, const char *file, int line);
extern unsigned long __io_phys_debug(unsigned long x, const char *file, int
li
ne);
#define __io_virt(x) __io_virt_debug((unsigned long)(x), __FILE__, __LINE__)
On 02.17 Paul Gortmaker wrote:
I was poking around in a vmlinux the other day and was surprised at the
amount of repetitive crap text that was in there. For example, try:
strings vmlinux|grep $PWD|wc -c
which gets some 70KB in my case - depends on strlen($PWD) obviously. The
culprit
On Sat, 17 Feb 2001 13:15:42 + (GMT),
Hugh Dickins [EMAIL PROTECTED] wrote:
On Sat, 17 Feb 2001, Paul Gortmaker wrote:
Anyway this small patch makes sure there is only one "kernel BUG..." string,
and dumps __FILE__ in favour of an address value since System.map data is
needed to make
On 02.18 Keith Owens wrote:
__C_FILE__ and __C_LINE__ refer to the .c or .s file that included the
header, so you get the exact location of the failing code instead of
the name and line number of a common header which is used all over the
place. __C_FILE__ would be replaced with the
On Sun, 18 Feb 2001 01:33:53 +0100,
"J . A . Magallon" [EMAIL PROTECTED] wrote:
Try this:
a.h:
#define hello printf("%d at %s\n",__LINE__,__FILE__)
a.c:
#include stdio.h
#include "a.h"
int main()
{
hello;
hello;
return 0;
}
werewolf:~/ko gcc a.c -o a
werewolf:~/ko a
6 at a.c
7 at
Keith Owens wrote:
But
a.h
static inline void hello(void) { printf("%d at %s\n",__LINE__,__FILE__); }
a.c
#include stdio.h
#include "a.h"
int main()
{
hello();
hello();
return 0;
}
# ./a
1 at a.h
1 at a.h
__BASE_FILE__ does this. It expands to the
On 02.18 Andrew Morton wrote:
__BASE_FILE__ does this. It expands to the thing which you
typed on the `gcc' command line.
..
3 at a.c
3 at a.c
I also thought that, but look at the line numbers...wrong and repeated.
--
J.A. Magallon
"J . A . Magallon" wrote:
On 02.18 Andrew Morton wrote:
__BASE_FILE__ does this. It expands to the thing which you
typed on the `gcc' command line.
..
3 at a.c
3 at a.c
I also thought that, but look at the line numbers...wrong and repeated.
Sure. There's no __BASE_LINE__.
I
On Sun, 18 Feb 2001 12:33:35 +1100,
Andrew Morton [EMAIL PROTECTED] wrote:
__BASE_FILE__ does this. It expands to the thing which you
typed on the `gcc' command line.
bix:/home/morton ./a.out
3 at a.c
3 at a.c
But __LINE__ is wrong. Forget what I said about __C_FILE__ and
__C_LINE__,
30 matches
Mail list logo
