booting problems
Quoted 12 lines
I think you're right. I'm sure now that the byte order isn't a problem, because my header and Jason's IPL work fine.
Quoted 7 lines
Jason's
link options, "-R 0 -N", specified a text origin of 0 and data following the text. I think the default for ELF is to place the text at0x1000and data at0x40000000. The gnu ld equivalent for "-R 0" would appear to be "-Ttext 0". I am not sure there is a direct equivalent for "-N". Maybe, you could use "-Tdata" to set the data location. Maps might be useful to sort out what is going on.
Quoted 2 lines
Definitely. This should be the next step in sorting this out.
The bootstrap definately will not work with default data at 0x40000000. The HPMC that is occurring is undoubtedly because the data section is there.
Quoted 12 lines · Jason Eckhardt
Quoted 12 lines
I think you're right. I'm sure now that the byte order isn't a problem, because my header and Jason's IPL work fine.
Quoted 7 lines
Jason's
link options, "-R 0 -N", specified a text origin of 0 and data following the text. I think the default for ELF is to place the text at0x1000and data at0x40000000. The gnu ld equivalent for "-R 0" would appear to be "-Ttext 0". I am not sure there is a direct equivalent for "-N". Maybe, you could use "-Tdata" to set the data location. Maps might be useful to sort out what is going on.
Quoted 5 lines
Quoted 2 lines
Definitely. This should be the next step in sorting this out.
The bootstrap definately will not work with default data at
0x40000000. The HPMC that is occurring is undoubtedly because the data section is there.
Okay, this is the same conclusion I came to. Where should I put both the data and text sengments?
- Alex
Quoted 2 lines
Okay, this is the same conclusion I came to. Where should I put both the data and text sengments?
Try this for the ld options: -Ttext 800 -N -s.
This links all sections in low virtual memory. VMA and LMA for the .text section are 0x800 (the size of the LIF header, 2048). The file offset to the .text section is 0xa0 bytes when -N is specified. The size of the LIF header should be 0x800 - 0xa0 = 0x760 (1888 bytes). The -s option strips the symbols.
The result of the link can be inspected with the command:
hppa-parisc-objdump --headers ipl
Hope this works.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Quoted 10 lines
Quoted 3 lines
Okay, this is the same conclusion I came to. Where should I put both the data and text sengments?
Try this for the ld options: -Ttext 800 -N -s.
This links all sections in low virtual memory. VMA and LMA for the .text section are
0x800(the size of the LIF header, 2048). The file offset to the .text section is0xa0bytes when -N is specified. The size of the LIF header should be0x800-0xa0=0x760(1888 bytes).
This last part may be unclear. What you need to arrange is that the offset to the .text section in the binary image is 0x800 bytes.
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Quoted 5 lines
Quoted 3 lines
Okay, this is the same conclusion I came to. Where should I put both the data and text sengments?
Try this for the ld options: -Ttext 800 -N -s.
On further inspection of the generated ipl file, it appears that a more complex script is needed to extract the section data. Here is the header dump of IPL created with the above link options:
ipl.N800: file format elf32-hppa
Sections:
Idx Name Size VMA LMA File off Algn 0 .text 00001b90 00000800 00000800 000000a0 2**4
CONTENTS, ALLOC, LOAD, CODE
1 .data 000064a8 00003000 00003000 000028a0 2**12
CONTENTS, ALLOC, LOAD, DATA
2 .bss 0000115c 0000f950 0000f950 00008d48 2**3
ALLOC
3 .PARISC.unwind 000000c0 00010aac 00010aac 00009a50 2**0
CONTENTS
4 .PARISC.symext 00000000 00010b6c 00010b6c 00009b10 2**2
CONTENTS
5 $CODE$ 00000d08 00010ba0 00010ba0 00008d48 2**3
CONTENTS, ALLOC, LOAD, CODE
The file offset for the .data section is ok. However, the .bss section must be created in the LIF image. The $CODE$ section is next in the file and it must be loaded at 10ba0 in the LIF image. Finally, the .PARISC.unwind and .PARISC.symext must be loaded to the correct locations in the LIF image.
It might be possible with a ld script to better arrange the sections and improve their placement in the linked file.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
In message <[email protected]>you write:
Quoted 2 lines
image. Finally, the .PARISC.unwind and .PARISC.symext must be loaded to the correct locations in the LIF image.
You can throw away the unwind & symext sections. While one day you might want the unwinders in your lif image, you'll never want the symext.
In the ELF tools, you shouldn't never end up with anything in $CODE$. If you do, that's a bug in either the compiler or the assembler. It should have mapped $CODE$ into .text.
jeff
Quoted 10 lines · Jeffrey A Law
In message <[email protected]>you write:
Quoted 2 lines
image. Finally, the .PARISC.unwind and .PARISC.symext must be loaded to the correct locations in the LIF image.
You can throw away the unwind & symext sections. While one day you might want the unwinders in your lif image, you'll never want the symext.
In the ELF tools, you shouldn't never end up with anything in $CODE$. If you do, that's a bug in either the compiler or the assembler. It should have mapped $CODE$ into .text.
Okay. So this means there's a problem with the GNU ld code. Jeff, do you know approximately where within the ld code we should be looking to fix this?
I confess I'm starting to get a little lost with the segment placings. Everything I'm trying is producing nothing at all. The latest I've tried is linking with:
parisc-linux-ld -m hppaelf -Ttext 0x1000 -N -s \
ipl_s.o ipl_c.o rom_interface.o ../../../lib/milli.o -o iplYou can inspect this kernel, it's at ftp://puffin.external.hp.com/pub/parisc/binaries/kernels/Image-19990612-1
The IPL starts at 0x1000.
It would be very helpful to get a PIM dump as Kirk had provided earlier.
- Alex
In message <[email protected]>you write:
Quoted 7 lines
Quoted 3 lines
In the ELF tools, you shouldn't never end up with anything in $CODE$. If you do, that's a bug in either the compiler or the assembler. It should have mapped $CODE$ into .text.
Okay. So this means there's a problem with the GNU ld code. Jeff, do you know approximately where within the ld code we should be looking to fix this?
No, it's in either gas or gcc, not gld.
To find it you first need to find the offending .o file. Then we'll look at the .s it's built from, then possibly walk backwards to the compiler itself depending on what we find.
To find the offending .o file with a $CODE$ use something like
objdump -h *.o ../../../lib/milli.o > /tmp/BLAH
Then search for $CODE$ in the resulting /tmp/BLAH. We'll work backwards from what you find.
Quoted 1 line
It would be very helpful to get a PIM dump as Kirk had provided earlier.
Look at trap.c in the Utah code. It had some of this kind of stuff. Though
it assumes that you can run long enough to get your own trap handlers installed.
jeff