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
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__,
"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 expan
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 m
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
> c
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 vmlinux
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 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
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:
>
Should
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
15 matches
Mail list logo