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 To: Fernando Nasser , 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 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 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 : > > > > 8060: e59f0458 ldr r0, [pc, #458] > > > > 8064: e5800000 str r0, [r0] > > > > > > > > 00008068 : > > > > 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 To: Jeremy Lin 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 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 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 : > > > > > 8060: e59f0458 ldr r0, [pc, #458] > > > > > 8064: e5800000 str r0, [r0] > > > > > > > > > > 00008068 : > > > > > 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 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 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 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 #include 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 * 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 To: Mark Kettenis 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: References: <200101222154.f0MLs4w00298@delius.kettenis.local> X-SW-Source: 2001-01/msg00157.html Content-length: 642 Mark Kettenis 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 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 To: Ulrich Drepper Cc: Mark Kettenis , 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> 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 To: Richard Henderson Cc: Mark Kettenis , 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: References: <200101222154.f0MLs4w00298@delius.kettenis.local> <20010122165817.A8117@redhat.com> X-SW-Source: 2001-01/msg00160.html Content-length: 1740 Richard Henderson 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 To: Richard Henderson Cc: Mark Kettenis , 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: References: <200101222154.f0MLs4w00298@delius.kettenis.local> <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 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 > 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 To: Mike Stump 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: References: <200101231121.DAA10091@kankakee.wrs.com> X-SW-Source: 2001-01/msg00163.html Content-length: 581 Mike Stump 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 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 : stmdb sp!, {r0, r1, r2, r3, lr} 0x2018eec : ldr r0, [lr, -#4] 0x2018ef0 : bic r0, r0, #-16777216 ; 0xff000000 0x2018ef4 : mov r1, sp 0x2018ef8 : mrs r2, SPSR 0x2018efc : stmdb sp!, {r2} 0x2018f00 : bl 0x2018d08 0x2018f04 : ldmia sp!, {r2} 0x2018f08 : msr SPSR_fc, r2 0x2018f0c : 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 To: Jens-Christian Lache Cc: crossgcc@sources.redhat.com, gdb@sources.redhat.com Subject: Re: gcc compile Date: Tue, 23 Jan 2001 09:29:00 -0000 Message-id: 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.