Hi,
Current git fails to compile for me with:
Building ld scripts (version "pre-0.6.2-20101219_191912-tata")
Traceback (most recent call last):
File "./tools/layoutrom.py", line 573, in <module>
main()
File "./tools/layoutrom.py", line 554, in main
info16 = parseObjDump(infile16, '16')
File "./tools/layoutrom.py", line 538, in parseObjDump
reloc.symbol = symbols[symbolname]
KeyError: '.rodata.__func__.2140'
make: *** [out/romlayout16.lds] Error 1
The interesting parts of the associated objdump are:
Sections:
Idx Name Size VMA LMA File off Algn
[...]
110 .rodata.__func__.2140 0000000a 00000000 00000000 000304fc 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
[...]
SYMBOL TABLE:
[...]
00000000 l O .rodata.__func__.2140 0000000a __func__.2140
[...]
00000000 l d .rodata.__func__.2140 00000000
[...]
RELOCATION RECORDS FOR [.debug_info]:
OFFSET TYPE VALUE
[...]
0001419f R_386_32 .rodata.__func__.2140
[...]
So the relocation record points to the section and not a symbol, and
the script dies. What can I do?
Best,
OG.
PS:
binutils-2.20.1
GNU objdump 2.15.92.0.2 20040927
gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2) (on x86_64)
Hi,
as part of a small exercise project for university I have to add a
custom software interrupt to the bios code which is then used by some
later booting stages. I already had a close look to the sourcefiles
and although I don't understand many of the stuff (I can read and
understand the individual parts but don't get the real big picture) I
have some anchorpoints which I think are necessary to complete my
work. I'd really appreciate if someone had a quick look on those
points and just confirmed or denied (maybe with other hints) them :)
1.) the IVT is set up in "post.c", to add my interrupt, I have to add
a line "SET_IVT(0x60, FUNC16(entry_60));" to init_ivt()
2.) romlayout.S contains the declarations for the IRQ handler, I have
to add a "DECL_IRQ_ENTRY_ARG 60" to the section "irqentryarg:"
3.) in my own .c-file I have to add a function "void VISIBLE16
handle_60(struct bregs *regs)" which receives the IRQ
4.) in this custom function I receive the set parameters from the
caller in the register-structure and also set my return values in this
5.) usable registers for arguments/return values are AX, BX, CX, DX,
DS, etc. I'd need DS:DX (analog to DOS) for passing a memory address
and CS:CX for a buffer size.
6.) the IRQ handler has to end with "set_success(regs);" or
"set_invalid(regs);" to return success/failure in CF (or should I use
AX for this and just call set_success?)
One last question: I chose IRQ 60 because it's stated as "user
defined" in "post.c". Should I use another one to not run into issues
with later stages of OS booting or will it just get overwritten at
some point?
Thanks in advance,
Kosi
Hi,
Here is a bunch of small fixes for the ahci driver which accumulated
over the last week.
[ v2: use pci_config_maskw, one patch updated ]
cheers,
Gerd
Gerd Hoffmann (4):
ahci: set dma feature flag
ahci: enable io/mem/dma
ahci: fix off-by-one in port count
ahci: set controller id
src/ahci.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
Hi,
Here is a bunch of small fixes for the ahci driver which accumulated
over the last week.
cheers,
Gerd
Gerd Hoffmann (4):
ahci: set dma feature flag
ahci: enable io/mem/dma
ahci: fix off-by-one in port count
ahci: set controller id
src/ahci.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
First of all, sorry for the very late reply, however, I thought I really
ought to offer my perspective on this:
On 11/25/2010 06:24 AM, Kevin O'Connor wrote:
> It's difficult to have a uniform view of the stack when transition
> modes, so pass the return address in a register. As a result, the
> transition functions only access memory via the %cs selector now.
I think this assertion is rather unfortunate, because my own experience
with thunking is that it is actually a very useful thing to have access
to the real-mode stack.
This is simply accomplished by computing a 32-bit register containing
the value (ss << 4) + sp, for example:
movzwl %sp, %eax
movl %ss, %ecx
shrl $4, %ecx
addl %ecx, %eax
This is particularly handy if there is a push/pop of the 16-bit register
set in the entry/exit sequence. Furthermore, pushing the target address
onto the stack rather than stuffing it into a register allows a 32-bit
routine to have full access to the 16-bit register image, whereas
burning a register means that that register is going to have to be
handled differently.
In Syslinux I have this formalized so that the sequence:
pushl $func32
callw _pm_call
... turns into the C function call:
void func32(com32sys_t *regs)
... where com32sys_t is a structure which contains the 16-bit register
image:
typedef struct {
uint16_t gs; /* Offset 0 */
uint16_t fs; /* Offset 2 */
uint16_t es; /* Offset 4 */
uint16_t ds; /* Offset 6 */
reg32_t edi; /* Offset 8 */
reg32_t esi; /* Offset 12 */
reg32_t ebp; /* Offset 16 */
reg32_t _unused_esp; /* Offset 20 */
reg32_t ebx; /* Offset 24 */
reg32_t edx; /* Offset 28 */
reg32_t ecx; /* Offset 32 */
reg32_t eax; /* Offset 36 */
reg32_t eflags; /* Offset 40 */
} com32sys_t;
This is simply the image created on the stack by the sequence (in NASM
syntax):
_pm_call:
pushfd
pushad
push ds
push es
push fs
push gs
This has been shown to be amazingly versatile, especially since the
16-bit register image can be not just observed but written directly.
One can implement this either with or without a stack switch (to do so
without a stack switch, the protected-mode ESP is computed from SS:SP).
However, since real-mode stacks tend to be very small -- often only a
few hundred bytes -- it is probably a bad idea.
In Syslinux this is actually implemeted in form of a lower-level
function which does indeed take an address in a register, so the two
approaches are not mutually exclusive. The actual full implementation
of the _pm_call routine looks like (note: this code assumes CS = 0).
;
; _pm_call: call PM routine in low memory from RM
;
; on stack = PM routine to call (a 32-bit address)
;
; ECX, ESI, EDI passed to the called function;
; EAX = EBP in the called function points to the stack frame
; which includes all registers (which can be changed if desired.)
;
; All registers and the flags saved/restored
;
; This routine is invoked by the pm_call macro.
;
_pm_call:
pushfd
pushad
push ds
push es
push fs
push gs
mov bp,sp
mov ax,cs
mov ebx,.pm
mov ds,ax
jmp enter_pm
bits 32
section .textnr
.pm:
; EAX points to the top of the RM stack, which is EFLAGS
test RM_FLAGSH,02h ; RM EFLAGS.IF
jz .no_sti
sti
.no_sti:
call [ebp+4*2+9*4+2] ; Entrypoint on RM stack
mov bx,.rm
jmp enter_rm
bits 16
section .text16
.rm:
pop gs
pop fs
pop es
pop ds
popad
popfd
ret 4 ; Drop entrypoint
The entire file including the enter_pm/enter_rm functions can be seen at:
http://tinyurl.com/2cjvt4a
-hpa
