* Re: gcc compile
[not found] <E14Kepn-0007CU-00@pig.labs.futuretv.com>
@ 2001-01-22 7:00 ` Jens-Christian Lache
0 siblings, 0 replies; only message in thread
From: Jens-Christian Lache @ 2001-01-22 7:00 UTC (permalink / raw)
To: crossgcc, gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 32771 bytes --]
Hello everybody! The ARM Simulator does support different Modes. I just have
had the wrong arm-elf-gdb in my PATH. It was the last stable version:
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
Even at the beginning of "start" the cpsr is equal to 0x10;
I have added a mode switch to user mode to crt0.S
and will install the proposed swi handler.
Thank´s a lot,
Jens-Christian
Am Mon, 22 Jan 2001 schrieben Sie:
> In message <01012211514701.02376@lab04>, Jens-Christian Lache writes:
> >Unfortunately the ARM simulator does not support the several CPU modes, that
> >the ARM7TDMI has. I made a software trap using "swi", and the pc was set
> >correctly to 0x8. It did also execute the jump instruction from this place
> >leading to my own swi handler. But when leaving it, returning to the
> >code containing the swi, the mode was still 0x10, which is not supervisor
> >mode.
>
> Can you give a concrete example of the code that you think is going wrong?
> The simulator certainly does support different modes - all ARM processors have
> these, not just ARM7TDMI.
>
> p.
--
Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756
From chienyul@yahoo.com Mon Jan 22 11:25:00 2001
From: Jeremy Lin <chienyul@yahoo.com>
To: Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Using gdb with JEENI
Date: Mon, 22 Jan 2001 11:25:00 -0000
Message-id: <20010122192510.6548.qmail@web2306.mail.yahoo.com>
X-SW-Source: 2001-01/msg00153.html
Content-length: 3291
Hi,
I updated to the newest version of Cygwin(1.1.7).
Now it works fine. I can single step it.
Thanks!
Jeremy
--- Fernando Nasser <fnasser@cygnus.com> wrote:
> Jeremy Lin wrote:
> >
> > It is cygwin 1.1, I installed in in August 2000.
> > Thanks!
> >
>
> Jeremy,
>
> I am not completely sure about this specific Cygwin version, but people have
> been getting good results with more recent versions. Maybe you should
> try upgrading to a recent Cygwin snapshot.
>
> Fernando
>
>
> > Jeremy Lin
> >
> > --- Fernando Nasser <fnasser@cygnus.com> wrote:
> > > Which version of Cygwin are you using?
> > >
> > > Jeremy Lin wrote:
> > > >
> > > > I have a problem using JEENI with GDB 5.0 debugging.
> > > > JEENI FirmwareVersion:2.0
> > > > Connected via serial port and RDI(tar rdi s=com2),
> > > > I'm doing the eCos porting to our customize board based on
> > > > Samsung KS32C50100 (ARM7TDMI core). Right now I'm debugging
> > > > the ROM image which initialize the board. The problem is, for example,
> > > > here is a sample instructions of the ROM image dump by gnu objdump:
> > > > 00008060 <reset_vector>:
> > > > 8060: e59f0458 ldr r0, [pc, #458]
> > > > 8064: e5800000 str r0, [r0]
> > > >
> > > > 00008068 <warm_reset>:
> > > > 8068: e3a00000 mov r0, #0 ; 0x0
> > > > 806c: e5800040 str r0, [r0, #64]
> > > > 8070: e59f144c ldr r1, [pc, #44c]
> > > > 8074: e5912008 ldr r2, [r1, #8]
> > > > 8078: e5802008 str r2, [r0, #8]
> > > > 807c: e5912040 ldr r2, [r1, #64]
> > > > 8080: e5802028 str r2, [r0, #40]
> > > > 8084: ef000000 swi 0x00000000
> > > >
> > > > when I set a breakpoint"b *0x8070" then "continue", it breaks
> > > > normally. But after that I type "stepi" to run next instruction.
> > > > This message comes out and gdb was terminated:
> > > >
> > > > 0 [main] arm-elf-gdb 1003 handle_exceptions: Exception: \
> > > > STATUS_ACCESS_VIOLATION
> > > > 21532 [main] arm-elf-gdb 1003 stackdump: Dumping stack trace to
> > > > arm-elf-gdb.exe.stack.dump
> > > > Segmentation fault (core dump)
> > > >
> > > > This happens also when I set the 2nd breakpoint (for example, at
> 0x8080)
> > > and
> > > > enter "continue". So I can only set one breakpoint at a time...
> > > > Does any one have the same problem?
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Get email at your own domain with Yahoo! Mail.
> > > > http://personal.mail.yahoo.com/
> > >
> > > --
> > > Fernando Nasser
> > > Red Hat - Toronto E-Mail: fnasser@redhat.com
> > > 2323 Yonge Street, Suite #300
> > > Toronto, Ontario M4P 2C9
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
>
> --
> Fernando Nasser
> Red Hat - Toronto E-Mail: fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario M4P 2C9
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
From fnasser@cygnus.com Mon Jan 22 11:36:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Jeremy Lin <chienyul@yahoo.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Using gdb with JEENI
Date: Mon, 22 Jan 2001 11:36:00 -0000
Message-id: <3A6C8B67.9DE28221@cygnus.com>
References: <20010122192510.6548.qmail@web2306.mail.yahoo.com>
X-SW-Source: 2001-01/msg00154.html
Content-length: 3788
Jeremy Lin wrote:
>
> Hi,
> I updated to the newest version of Cygwin(1.1.7).
> Now it works fine. I can single step it.
> Thanks!
>
> Jeremy
>
Thank you for letting us know. If someone else runs into the same
problem they can look at the list archives and figure what to do.
Regards,
Fernando
> --- Fernando Nasser <fnasser@cygnus.com> wrote:
> > Jeremy Lin wrote:
> > >
> > > It is cygwin 1.1, I installed in in August 2000.
> > > Thanks!
> > >
> >
> > Jeremy,
> >
> > I am not completely sure about this specific Cygwin version, but people have
> > been getting good results with more recent versions. Maybe you should
> > try upgrading to a recent Cygwin snapshot.
> >
> > Fernando
> >
> >
> > > Jeremy Lin
> > >
> > > --- Fernando Nasser <fnasser@cygnus.com> wrote:
> > > > Which version of Cygwin are you using?
> > > >
> > > > Jeremy Lin wrote:
> > > > >
> > > > > I have a problem using JEENI with GDB 5.0 debugging.
> > > > > JEENI FirmwareVersion:2.0
> > > > > Connected via serial port and RDI(tar rdi s=com2),
> > > > > I'm doing the eCos porting to our customize board based on
> > > > > Samsung KS32C50100 (ARM7TDMI core). Right now I'm debugging
> > > > > the ROM image which initialize the board. The problem is, for example,
> > > > > here is a sample instructions of the ROM image dump by gnu objdump:
> > > > > 00008060 <reset_vector>:
> > > > > 8060: e59f0458 ldr r0, [pc, #458]
> > > > > 8064: e5800000 str r0, [r0]
> > > > >
> > > > > 00008068 <warm_reset>:
> > > > > 8068: e3a00000 mov r0, #0 ; 0x0
> > > > > 806c: e5800040 str r0, [r0, #64]
> > > > > 8070: e59f144c ldr r1, [pc, #44c]
> > > > > 8074: e5912008 ldr r2, [r1, #8]
> > > > > 8078: e5802008 str r2, [r0, #8]
> > > > > 807c: e5912040 ldr r2, [r1, #64]
> > > > > 8080: e5802028 str r2, [r0, #40]
> > > > > 8084: ef000000 swi 0x00000000
> > > > >
> > > > > when I set a breakpoint"b *0x8070" then "continue", it breaks
> > > > > normally. But after that I type "stepi" to run next instruction.
> > > > > This message comes out and gdb was terminated:
> > > > >
> > > > > 0 [main] arm-elf-gdb 1003 handle_exceptions: Exception: \
> > > > > STATUS_ACCESS_VIOLATION
> > > > > 21532 [main] arm-elf-gdb 1003 stackdump: Dumping stack trace to
> > > > > arm-elf-gdb.exe.stack.dump
> > > > > Segmentation fault (core dump)
> > > > >
> > > > > This happens also when I set the 2nd breakpoint (for example, at
> > 0x8080)
> > > > and
> > > > > enter "continue". So I can only set one breakpoint at a time...
> > > > > Does any one have the same problem?
> > > > >
> > > > > __________________________________________________
> > > > > Do You Yahoo!?
> > > > > Get email at your own domain with Yahoo! Mail.
> > > > > http://personal.mail.yahoo.com/
> > > >
> > > > --
> > > > Fernando Nasser
> > > > Red Hat - Toronto E-Mail: fnasser@redhat.com
> > > > 2323 Yonge Street, Suite #300
> > > > Toronto, Ontario M4P 2C9
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Get email at your own domain with Yahoo! Mail.
> > > http://personal.mail.yahoo.com/
> >
> > --
> > Fernando Nasser
> > Red Hat - Toronto E-Mail: fnasser@redhat.com
> > 2323 Yonge Street, Suite #300
> > Toronto, Ontario M4P 2C9
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From ngupta@zumanetworks.com Mon Jan 22 13:36:00 2001
From: Niraj Gupta <ngupta@zumanetworks.com>
To: gdb@sources.redhat.com
Subject: symbol table incorrect with add-symbol-file command
Date: Mon, 22 Jan 2001 13:36:00 -0000
Message-id: <01012213364701.17957@bugs>
X-SW-Source: 2001-01/msg00155.html
Content-length: 688
we are using one of the latest snapshot of the tree (jan 2001 2-week)
part of our symbol table is added using the add-symbol-file command
the target is powerpc-linux compiler verion is 2.92.2, all the symbols show
up correctly except for
global static symbols, this can be recreated with following
/* test.c */
#define LEN 16
static unsigned char a[LEN];
static unsigned char b[LEN];
clear()
{
int i;
for(i=0;i<LEN;i++)
a[i] = b[i] = 0;
}
compile with
powerpc-linux-gcc -c -g test.c
gdb> add-symbol-file test.c 0x1000 -s .data 0x2000 -s .bss 0x3000
gdb>p/x &a
0x3000
gdb> p/x &b
0x3000
/* here the address of b is incorrect, it should be 0x3010 */
please help
From kettenis@wins.uva.nl Mon Jan 22 13:54:00 2001
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gcc@gcc.gnu.org
Cc: gdb@sources.redhat.com, drepper@redhat.com, rth@redhat.com
Subject: Bug in dwarf2out.c:output_file_names()
Date: Mon, 22 Jan 2001 13:54:00 -0000
Message-id: <200101222154.f0MLs4w00298@delius.kettenis.local>
X-SW-Source: 2001-01/msg00156.html
Content-length: 3412
Hi,
There seems to be a problem with the code that writes the directory
table and file name table for DWARF2.
Suppose you have the file src/hello.c:
#include <stdio.h>
#include <stdlib.h>
int
main (void)
{
printf ("Hello, World!\n");
return EXIT_SUCCESS;
}
And now do (on a system with an assembler that doesn't support the
DWARF2 .file an .loc directives):
$ gcc -g -dA -S src/hello.c
the resulting assembly for the start of the .debug_line section looks
like:
.section .debug_line
.4byte .LTEND-.LTSTART # Length of Source Line Info.
.LTSTART:
.2byte 0x2 # DWARF Version
.4byte 0x94 # Prolog Length
.byte 0x4 # Minimum Instruction Length
.byte 0x1 # Default is_stmt_start flag
.byte -10 # Line Base Value (Special Opcodes)
.byte 245 # Line Range Value (Special Opcodes)
.byte 10 # Special Opcode Base
.byte 0x0 # opcode: 0x1 has 0 args
.byte 0x1 # opcode: 0x2 has 1 args
.byte 0x1 # opcode: 0x3 has 1 args
.byte 0x1 # opcode: 0x4 has 1 args
.byte 0x1 # opcode: 0x5 has 1 args
.byte 0x0 # opcode: 0x6 has 0 args
.byte 0x0 # opcode: 0x7 has 0 args
.byte 0x0 # opcode: 0x8 has 0 args
.byte 0x1 # opcode: 0x9 has 1 args
.byte 0x0 # End directory table
.ascii "hello.c\0" # File Entry: 0x1
.byte 0x0 # ULEB128 0x0
.byte 0x0 # ULEB128 0x0
.byte 0x0 # ULEB128 0x0
.byte 0x0 # End file name table
Note that the directory table is empty, and the only the last
component of the path is stored in the file name table. It's needless
to say that this greatly confuses the GDB, resulting in a lot of
testsuite failures when running the testsuite on a system where DWARF2
is the default debugging format.
The problems stem from the following line in
dwarf2out.c:output_file_names():
idx_offset = dirs[0].path[0] == '/' ? 1 : 0;
the result is that the first directory isn't emitted if it doesn't
start with a slash, presumably to avoid emitting an empty directory
entry when compiling source files from the current directory.
However, as I explained before, this loses for relative path names.
Im not exactly sure how the code is supposed to work, but wouldn't
replacing the line above with:
idx_offset = dirs[0].length > 0 ? 1 : 0;
work? It seems to do so for me, although I didn't run the testsuite.
A patch is attached, feel free to use it.
Thanks,
Mark
2001-01-22 Mark Kettenis <kettenis@gnu.org>
* dwarf2out.c (output_file_names): Set idx_offset to 1 based on
the path length instead of whether it starts with a slash.
Index: dwarf2out.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/dwarf2out.c,v
retrieving revision 1.233
diff -u -p -r1.233 dwarf2out.c
--- dwarf2out.c 2001/01/19 17:11:15 1.233
+++ dwarf2out.c 2001/01/22 21:52:23
@@ -6671,7 +6671,7 @@ output_file_names ()
confuse these indices with the one for the constructed table
(even though most of the time they are identical). */
idx = 1;
- idx_offset = dirs[0].path[0] == '/' ? 1 : 0;
+ idx_offset = dirs[0].length > 0 ? 1 : 0;
for (i = 1 - idx_offset; i < ndirs; ++i)
if (dirs[i].used != 0)
{
From drepper@redhat.com Mon Jan 22 14:08:00 2001
From: Ulrich Drepper <drepper@redhat.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gcc@gcc.gnu.org, gdb@sources.redhat.com, rth@redhat.com
Subject: Re: Bug in dwarf2out.c:output_file_names()
Date: Mon, 22 Jan 2001 14:08:00 -0000
Message-id: <m34ryri6io.fsf@otr.mynet.cygnus.com>
References: <200101222154.f0MLs4w00298@delius.kettenis.local>
X-SW-Source: 2001-01/msg00157.html
Content-length: 642
Mark Kettenis <kettenis@wins.uva.nl> writes:
> idx_offset = dirs[0].length > 0 ? 1 : 0;
>
> work? It seems to do so for me, although I didn't run the testsuite.
> A patch is attached, feel free to use it.
I think the patch is correct. The sorting function ensures that all
entries without a directory part come first and this test is there to
check for these entries. But some gcc person has to say it's OK, too.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
From dancy@franz.com Mon Jan 22 15:19:00 2001
From: Ahmon Dancy <dancy@franz.com>
To: gdb@sourceware.cygnus.com
Subject: GDB and 64-bit solaris
Date: Mon, 22 Jan 2001 15:19:00 -0000
Message-id: <200101222319.PAA08762@ultra.franz.com>
X-SW-Source: 2001-01/msg00158.html
Content-length: 55
Is gdb 5.0 supposed to handle Solaris 64-bit binaries?
From rth@redhat.com Mon Jan 22 16:58:00 2001
From: Richard Henderson <rth@redhat.com>
To: Ulrich Drepper <drepper@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gcc@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: Bug in dwarf2out.c:output_file_names()
Date: Mon, 22 Jan 2001 16:58:00 -0000
Message-id: <20010122165817.A8117@redhat.com>
References: <200101222154.f0MLs4w00298@delius.kettenis.local> <m34ryri6io.fsf@otr.mynet.cygnus.com>
X-SW-Source: 2001-01/msg00159.html
Content-length: 933
On Mon, Jan 22, 2001 at 02:09:03PM -0800, Ulrich Drepper wrote:
> I think the patch is correct. The sorting function ensures that all
> entries without a directory part come first and this test is there to
> check for these entries. But some gcc person has to say it's OK, too.
I've spent a bit of time looking at this code today, and
I don't think that it is working at all. Consider
#line 1 "longlonglong/a/z.c"
int foo() { return 0; }
#line 1 "longlonglong/b/z.c"
int bar() { return 0; }
As I understand what this code is attempting to do, we should
get one directory entry for "longlonglong" and files "a/z.c"
and "b/z.c". But we don't.
Moreover, I think that the existance of idx_offset at all displays
a fundamental confusion with handling CWD and dir_idx being zero
based or one based.
Uli, you wrote this code in the first place. Care to fix it?
Failing that, I'd just as soon rip it out.
r~
From drepper@redhat.com Mon Jan 22 18:08:00 2001
From: Ulrich Drepper <drepper@redhat.com>
To: Richard Henderson <rth@redhat.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gcc@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: Bug in dwarf2out.c:output_file_names()
Date: Mon, 22 Jan 2001 18:08:00 -0000
Message-id: <m3zogjf2b1.fsf@otr.mynet.cygnus.com>
References: <200101222154.f0MLs4w00298@delius.kettenis.local> <m34ryri6io.fsf@otr.mynet.cygnus.com> <20010122165817.A8117@redhat.com>
X-SW-Source: 2001-01/msg00160.html
Content-length: 1740
Richard Henderson <rth@redhat.com> writes:
> I don't think that it is working at all. Consider
>
> #line 1 "longlonglong/a/z.c"
> int foo() { return 0; }
>
> #line 1 "longlonglong/b/z.c"
> int bar() { return 0; }
>
> As I understand what this code is attempting to do, we should
> get one directory entry for "longlonglong" and files "a/z.c"
> and "b/z.c". But we don't.
Right, and this was intended. The problem is that handling this case
can have the number of prefixes which have to be examined grow by
large amounts. One will have to look at every prefix. I can
implement this and in general the compiler runtime will not be
increased but with many files in very different directories the
runtime can grow nonlinear. It's unlikely but could happen.
Note what happens if you add to your example above the lines
#line 1 "longlonglong/c"
int baz() { return 0; }
This is more probably to happen. Just assume
/usr/include
/usr/include/sys
/usr/include/bits
> Moreover, I think that the existance of idx_offset at all displays
> a fundamental confusion with handling CWD and dir_idx being zero
> based or one based.
Not really. One could probably rewrite the code to drop the variable
but the code should be fine with Mark's patch.
> Uli, you wrote this code in the first place. Care to fix it?
I can *extend* the code, or at least propose a patch.
> Failing that, I'd just as soon rip it out.
This shouldn't be necessary in any case since the changed code works
just fine.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
From drepper@redhat.com Tue Jan 23 00:47:00 2001
From: Ulrich Drepper <drepper@redhat.com>
To: Richard Henderson <rth@redhat.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gcc@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: Bug in dwarf2out.c:output_file_names()
Date: Tue, 23 Jan 2001 00:47:00 -0000
Message-id: <m3y9w2ejsm.fsf@otr.mynet.cygnus.com>
References: <200101222154.f0MLs4w00298@delius.kettenis.local> <m34ryri6io.fsf@otr.mynet.cygnus.com> <20010122165817.A8117@redhat.com>
X-SW-Source: 2001-01/msg00161.html
Content-length: 4242
With a bit of thinking I came up with the appended patch. It should
catch the cases rth mentioned without much increase in compile time.
We have at most twice at many entries.
I'll do a bit more testing today but you might want to review it now.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Index: dwarf2out.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/dwarf2out.c,v
retrieving revision 1.233
diff -u -d -u -p -r1.233 dwarf2out.c
--- dwarf2out.c 2001/01/19 17:11:15 1.233
+++ dwarf2out.c 2001/01/23 08:45:49
@@ -6499,6 +6499,36 @@ file_info_cmp (p1, p2)
}
}
+/* Compute the maximum prefix of P2 appearing also in P1. Entire
+ directory names must match. */
+static int prefix_of PARAMS ((struct dir_info *, struct dir_info *));
+static int
+prefix_of (p1, p2)
+ struct dir_info *p1;
+ struct dir_info *p2;
+{
+ char *s1 = p1->path;
+ char *s2 = p2->path;
+
+ /* The algorithm in `output_file_names' must ensure that the already
+ added entries have no longer directory names. */
+ if (p1->length > p2->length)
+ abort ();
+
+ while (*s1 == *s2 && s1 < p1->path + p1->length)
+ ++s1, ++s2;
+
+ if (*s1 == '/' && *s2 == '/')
+ /* The whole of P1 is the prefix. */
+ return p1->length;
+
+ /* Go back to the last directory component. */
+ while (s1 > p1->path && *--s1 != '/')
+ /* go */;
+
+ return s1 - p1->path + 1;
+}
+
/* Output the directory table and the file name table. We try to minimize
the total amount of memory needed. A heuristic is used to avoid large
slowdowns with many input files. */
@@ -6518,7 +6548,7 @@ output_file_names ()
/* Allocate the various arrays we need. */
files = (struct file_info *) alloca (line_file_table.in_use
* sizeof (struct file_info));
- dirs = (struct dir_info *) alloca (line_file_table.in_use
+ dirs = (struct dir_info *) alloca (line_file_table.in_use * 2
* sizeof (struct dir_info));
/* Sort the file names. */
@@ -6567,6 +6597,8 @@ output_file_names ()
else
{
int j;
+ int max_idx;
+ int max_len;
/* This is a new directory. */
dirs[ndirs].path = files[i].path;
@@ -6578,12 +6610,44 @@ output_file_names ()
files[i].dir_idx = ndirs;
/* Search for a prefix. */
- dirs[ndirs].prefix = -1;
+ max_len = 0;
+ max_idx = 0;
for (j = 0; j < ndirs; ++j)
- if (dirs[j].length < dirs[ndirs].length
- && dirs[j].length != 0
- && memcmp (dirs[j].path, dirs[ndirs].path, dirs[j].length) == 0)
- dirs[ndirs].prefix = j;
+ if (dirs[j].length > max_len)
+ {
+ int this_len = prefix_of (&dirs[j], &dirs[ndirs]);
+
+ if (this_len > max_len)
+ {
+ max_len = this_len;
+ max_idx = j;
+ }
+ }
+
+ /* Remember the prefix. If this is a known prefix simply
+ remember the index. Otherwise we will have to create an
+ artificial entry. */
+ if (max_len == dirs[max_idx].length)
+ /* This is our prefix. */
+ dirs[ndirs].prefix = max_idx;
+ else
+ {
+ /* Create an entry without associated file. Since we have
+ to keep the dirs array sorted (means, entries with paths
+ which come first) we have to move the new entry in the
+ place of the old one. */
+ dirs[++ndirs] = dirs[max_idx];
+
+ /* We don't have to set .path. */
+ dirs[max_idx].length = max_len;
+ dirs[max_idx].nbytes = 0;
+ dirs[max_idx].count = 0;
+ dirs[max_idx].dir_idx = ndirs;
+ dirs[max_idx].used = 0;
+ dirs[max_idx].prefix = dirs[ndirs].prefix;
+
+ dirs[ndirs - 1].prefix = dirs[ndirs].prefix = max_idx;
+ }
++ndirs;
}
@@ -6671,7 +6735,7 @@ output_file_names ()
confuse these indices with the one for the constructed table
(even though most of the time they are identical). */
idx = 1;
- idx_offset = dirs[0].path[0] == '/' ? 1 : 0;
+ idx_offset = dirs[0].length > 0 ? 1 : 0;
for (i = 1 - idx_offset; i < ndirs; ++i)
if (dirs[i].used != 0)
{
From mrs@windriver.com Tue Jan 23 03:22:00 2001
From: Mike Stump <mrs@windriver.com>
To: drepper@cygnus.com, rth@redhat.com
Cc: gcc@gcc.gnu.org, gdb@sources.redhat.com, kettenis@wins.uva.nl
Subject: Re: Bug in dwarf2out.c:output_file_names()
Date: Tue, 23 Jan 2001 03:22:00 -0000
Message-id: <200101231121.DAA10091@kankakee.wrs.com>
X-SW-Source: 2001-01/msg00162.html
Content-length: 566
> From: Ulrich Drepper <drepper@redhat.com>
> Date: 23 Jan 2001 00:48:09 -0800
> With a bit of thinking I came up with the appended patch.
> + if (*s1 == '/' && *s2 == '/')
If '/' is speced as the only possible prefix than this is ok. If this
code has to work on Windows, where A:/foo A:\foo \foo are all
prefixes, then the code is wrong. Please look around for other places
where this test is done for the right incantation. (binutils/gcc) If
you wrap the use in is_absolute (name) you will make it easier to win,
if you don't feel like doing the work now.
From drepper@redhat.com Tue Jan 23 08:17:00 2001
From: Ulrich Drepper <drepper@redhat.com>
To: Mike Stump <mrs@windriver.com>
Cc: rth@redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com, kettenis@wins.uva.nl
Subject: Re: Bug in dwarf2out.c:output_file_names()
Date: Tue, 23 Jan 2001 08:17:00 -0000
Message-id: <m33deadyzk.fsf@otr.mynet.cygnus.com>
References: <200101231121.DAA10091@kankakee.wrs.com>
X-SW-Source: 2001-01/msg00163.html
Content-length: 581
Mike Stump <mrs@windriver.com> writes:
> If '/' is speced as the only possible prefix than this is ok. If this
> code has to work on Windows, where A:/foo A:\foo \foo are all
> prefixes, then the code is wrong.
I have not the slightest clue about this and will definitely not learn
it. Things like this must be handled by people who know what they
expect.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
From lache@tu-harburg.de Tue Jan 23 09:21:00 2001
From: Jens-Christian Lache <lache@tu-harburg.de>
To: crossgcc@sources.redhat.com, gdb@sources.redhat.com
Subject: Re: gcc compile
Date: Tue, 23 Jan 2001 09:21:00 -0000
Message-id: <0101231819220B.02452@lab04>
X-SW-Source: 2001-01/msg00164.html
Content-length: 5692
Hi everybody!
Since a few day´s I try to make software trap´s using "swi" on the ARM
simulator build in gdb. I have tested the code on "real" hardware, it worked
fine. My hardware has a monitor program (angel), which is initializing the
superuser side and switches the proc to user mode before starting the
code at "start" from the crt0.S file.
I still can´t do these sw traps on the simulator. I get:
unknown SWI encountered - 1 - ignoring
unknown SWI encountered - 2 - ignoring
unknown SWI encountered - 3 - ignoring
unknown SWI encountered - 4 - ignoring
for
asm volatile (".equ REASON_CHANGE_TO_SV, 0x0");
asm volatile (".equ REASON_SET_I, 0x1");
asm volatile (".equ REASON_UNSET_I, 0x2");
asm volatile (".equ REASON_SET_F, 0x3");
asm volatile (".equ REASON_UNSET_F, 0x4");
asm volatile ("swi #REASON_CHANGE_TO_SV");
asm volatile ("swi #REASON_SET_I");
asm volatile ("swi #REASON_UNSET_I");
asm volatile ("swi #REASON_SET_F");
(it does not complain about "swi 0x0", if you may have noticed). I am sure that
it does not enter the function
Dump of assembler code for function swi_wrapper__Fv:
0x2018ee8 <swi_wrapper__Fv>: stmdb sp!, {r0, r1, r2, r3, lr}
0x2018eec <swi_wrapper__Fv+4>: ldr r0, [lr, -#4]
0x2018ef0 <swi_wrapper__Fv+8>: bic r0, r0, #-16777216 ; 0xff000000
0x2018ef4 <swi_wrapper__Fv+12>: mov r1, sp
0x2018ef8 <swi_wrapper__Fv+16>: mrs r2, SPSR
0x2018efc <swi_wrapper__Fv+20>: stmdb sp!, {r2}
0x2018f00 <swi_wrapper__Fv+24>: bl 0x2018d08 <swi_handler__FiPUi>
0x2018f04 <swi_wrapper__Fv+28>: ldmia sp!, {r2}
0x2018f08 <swi_wrapper__Fv+32>: msr SPSR_fc, r2
0x2018f0c <swi_wrapper__Fv+36>: ldmia sp!, {r0, r1, r2, r3, pc}
End of assembler dump.
which is initialized by
memPointer = TABLE_ENTRY_SWI_HANDLER_ADDRESS; // 0x20
*memPointer = (int) swi_wrapper;
memPointer = JUMP_DESTINATION_SWI; // 0x8
*memPointer= 0xe59ff010;
The swi_wrapper leads to :
void swi_handler(int swi_number, unsigned int * stack ) {
38 static Logger swiLogger((int *) 0x100, (int *) 0x200);
39 int cpsr;
40
- 41 switch(swi_number) {
42 case REASON_CHANGE_TO_SV :
- 43 os->osLogger->log("REASON_CHANGE_TO_SV",0);
- 44 break;
45 case REASON_SET_I:
- 46 asm volatile ("mrs r0,cpsr": : :"r0");
- 47 asm volatile ("orr r0, r0, #128": : :"r0");
- 48 asm volatile ("msr cpsr, r0");
- 49 asm volatile ("mrs %0, cpsr":"=r" (cpsr));
- 50 os->osLogger->log("REASON_SET_I",cpsr);
- 51 break;
52 case REASON_UNSET_I:
- 53 asm volatile ("mrs r0,cpsr": : :"r0");
- 54 asm volatile ("and r0, r0, #0xffff7fff": : :"r0");
- 55 asm volatile ("msr cpsr, r0");
- 56 asm volatile ("mrs %0, cpsr":"=r" (cpsr));
- 57 os->osLogger->log("REASON_UNSET_I",cpsr);
- 58 break;
59 case REASON_SET_F:
- 60 asm volatile ("mrs r0,cpsr": : :"r0");
- 61 asm volatile ("orr r0, r0, #64": : :"r0");
- 62 asm volatile ("msr cpsr, r0");
- 63 asm volatile ("mrs %0, cpsr":"=r" (cpsr));
- 64 os->osLogger->log("REASON_SET_F",cpsr);
- 65 break;
66 case REASON_UNSET_F:
- 67 asm volatile ("mrs r0,cpsr": : :"r0");
- 68 asm volatile ("and r0, r0, #0xffffbfff": : :"r0");
- 69 asm volatile ("msr cpsr, r0");
- 70 asm volatile ("mrs %0, cpsr":"=r" (cpsr));
- 71 os->osLogger->log("REASON_UNSET_F",cpsr);
- 72 break;
73 default :
- 74 break;
The logging facility is tested and works fine on the aeb.
Is there still an error in the crt0.S file or could this be a bug of the gdb?
Thank´s for your patience with me :-),
Jens-Christian
P.S.:
The beginning of the crt0.S file with my modification:
//#include "swi.h"
/* ANSI concatenation macros. */
#define CONCAT(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b
#ifdef __USER_LABEL_PREFIX__
#define FUNCTION( name ) CONCAT (__USER_LABEL_PREFIX__, name)
#else
#error __USER_LABEL_PREFIX is not defined
#endif
/* .text is used instead of .section .text so it works with arm-aout too. */
.text
.code 32
.align 0
.global _mainCRTStartup
.global _start
.global start
start:
_start:
_mainCRTStartup:
/* Start by setting up a stack */
#ifdef ARM_RDP_MONITOR
/* Issue Demon SWI to read stack info */
swi SWI_GetEnv /* Returns command line in r0 */
mov sp,r1 /* and the highest memory address in r1 */
ldr sl, .LC2 /* stack limit is at end of data */
add sl, sl, #256 /* allow slop for stack overflow handling */
/* and small frames */
#else
#ifdef ARM_RDI_MONITOR
/* Issue Angel SWI to read stack info */
mov r0, #AngelSWI_Reason_HeapInfo
adr r1, .LC0 /* point at ptr to 4 words to receive data */
swi AngelSWI_ARM /* We are always in ARM mode for startup */
ldr r0, .LC0 /* point at values read */
ldr sp, [r0, #8]
ldr sl, [r0, #12]
add sl, sl, #256 /* allow slop for stack overflow handling */
/* and small frames */
#else
/* Set up the stack pointer to a fixed value */
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ modification, jens-christian
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ begin
// switch to user mode
.equ MODE_BITS, 0x1F @ all mode bits from cpsr
.equ USER_MODE, 0x10 @ b10000 is user mode
#ifdef TARGET_SIM
@ initialize the stack pointer
@ for SV mode
@ set sp to the end of the RAM (eb01)
mov sp, #0x1000
// switch to user mode
mrs r0, cpsr
bic r0, r0, #MODE_BITS
orr r0, r0, #USER_MODE
msr cpsr, r0
#endif //TARGET_SIM
@ end
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ldr r3, .LC0
mov sp, r3
/* Setup a default stack-limit in-case the code has been
--
Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756
From pb@futuretv.com Tue Jan 23 09:29:00 2001
From: Philip Blundell <pb@futuretv.com>
To: Jens-Christian Lache <lache@tu-harburg.de>
Cc: crossgcc@sources.redhat.com, gdb@sources.redhat.com
Subject: Re: gcc compile
Date: Tue, 23 Jan 2001 09:29:00 -0000
Message-id: <E14L7Fa-0000Sg-00@pig.labs.futuretv.com>
References: <0101231819220B.02452@lab04>
X-SW-Source: 2001-01/msg00165.html
Content-length: 546
In message < 0101231819220B.02452@lab04 >, Jens-Christian Lache writes:
>unknown SWI encountered - 1 - ignoring
>unknown SWI encountered - 2 - ignoring
>unknown SWI encountered - 3 - ignoring
>unknown SWI encountered - 4 - ignoring
It doesn't think you've installed a SWI handler.
>which is initialized by
>
>memPointer = TABLE_ENTRY_SWI_HANDLER_ADDRESS; // 0x20
>*memPointer = (int) swi_wrapper;
>memPointer = JUMP_DESTINATION_SWI; // 0x8
>*memPointer= 0xe59ff010;
Are you certain that this code executes? How is `memPointer' defined?
p.
^ permalink raw reply [flat|nested] only message in thread