laaron has quit [Remote host closed the connection]
<HelloThere54321>
I am trying to use inline assembly to read the GDT using the sgdt instruction. My current attempt is: table = asm volatile ("sgdt %[tab]" : [tab] "=m" (-> GDT_PTR_struct));
<HelloThere54321>
i have, but im not sure what the 2nd part of the '[tab] "=m" (-> GDT_PTR_struct)' should ne as the sgdt instruction needs a memory location no a register
<samtebbs>
HelloThere54321: What does it compile to?
<HelloThere54321>
the example doesn't compile
<HelloThere54321>
thats the thing, im not sure Zig supports "=m" option so was wondering if there was another way
<FireFox317>
I think that we support the memory option, but your syntax doesn't look right to me. You are missing some colons at the end.
<samtebbs>
HelloThere54321: It should support it since it's part of the llvm specs
<samtebbs>
I'm getting a segfault when using that above so it must be a bug
<FireFox317>
You are using sgdt, which is for storing the gdb and when you want to read the gdt you want to use lgdt.
<samtebbs>
FireFox317: lgdt is used for telling the CPU where the gdt is
<FireFox317>
Then the inline assembly syntax works like this: asm volatile ("some assembly" : outputs : inputs : clobbers ). If you for example don't use any inputs you can keep them empty, but you still need to put the collons there.
<samtebbs>
sgdt copies the previously loaded gdt into the operand
<FireFox317>
samtebbs: Ah yes, that is correct my bad
<samtebbs>
FireFox317: No problem :)
<samtebbs>
I'd personally like the names to be swapped
<samtebbs>
That makes more sense
<samtebbs>
A workaround for now would be to link with an external assembly routine
<FireFox317>
HelloThere54321: This works: asm volatile ("sgdt %[tab]" : : [tab] "m"(x) : "memory"); You need a variable x in which the result will be stored
<FireFox317>
I didnt check the generated assembly, but it compiles :)
laaron has joined #zig
<HelloThere54321>
ill try
<Sahnvour>
HelloThere54321: note that inline asm support is still not complete and you may encounter bugs and/or limitations pretty quickly
<HelloThere54321>
i have var p = u48(0); asm volatile ("sgdt %[mem]" : : [mem] "m" (p) : "memory" ); Bur p is still 0
<FireFox317>
Maybe you want to pass in the address of p: &p
<FireFox317>
[mem] "m" (&p)
<HelloThere54321>
it gave some kind of result, but not what i was expecting
<FireFox317>
With some help of google, this gives the correct result i think: asm volatile ("sgdt %[tab]" : [tab] "=m"(x) : : "memory");
<HelloThere54321>
:O
<HelloThere54321>
it worked, thank you
<HelloThere54321>
is there a good website to learn this inline assembly
<FireFox317>
No problem! If you have any more question, feel free to ask
<FireFox317>
And actually in this case i think you can remove the "memory" clobber, because the memory is not being changed.
<FireFox317>
And then the extra colons can be removed as well XD: `asm volatile ("sgdt %[mem]" : [mem] "=m"(x));`
HelloThere54321 has quit [Ping timeout: 260 seconds]
dimenus has joined #zig
FireFox317 has quit [Remote host closed the connection]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
FireFox317 has joined #zig
<samtebbs>
Does anyone have much experience with linker scripts? I'd like to add a start and end symbol around each debug info section
<samtebbs>
I've tried doing this for each debug info section but the executable ends up having duplicates of each section
<samtebbs>
.debug.info ALIGN(4K) : AT (ADDR(.debug.info) - KERNEL_ADDR_OFFSET) {
<samtebbs>
DEBUG_INFO_START = .;
<samtebbs>
*(.debug.info)
<samtebbs>
DEBUG_INFO_END = .;
<samtebbs>
}
dimenus has quit [Remote host closed the connection]
<FireFox317>
samtebbs: I'm not sure if the ADDR(.debug.info) makes sense, because AT specifies where it should be placed and thus that determines the ADDR.
donaldallen has joined #zig
<samtebbs>
FireFox317: Well it seems to have a pre-defined address before evaluating the AT part
<samtebbs>
That is needed since my kernel is in the higher half
<FireFox317>
Ah yeah, nvm that is the load address indeed. Seems weird why it would make a duplicate of the section
<donaldallen>
What is the correct way to define a null pointer to pass to a C routine. Sqlite, for example, takes null pointers in many arguments of its C API. Suppose the (C) type of the parameter that can be null is 'const char **pzTail'. What is the correct way to define a null pointer to pass to this?
halosghost has joined #zig
<samtebbs>
FireFox317: it is weird indeed. I hope there's a way to stop it from being duplicated elsewhere
<samtebbs>
donaldallen: All C pointers are translated are optionals in Zig's eyes, so passing `null` should work
<FireFox317>
samtebbs: Maybe when you define the symbols outside the section it works?
<donaldallen>
samtebbs: Thanks -- I will give it a try.
<FireFox317>
Hmm, comparing the result with other binaries, it is the ALLOC option in debug.info that is present in your binary and not in others
<samtebbs>
Wait I might be dumb
<samtebbs>
The second set of debug sections all have underscores instead of dots...
dimenus has joined #zig
<samtebbs>
Yep, that was it :facepalm:
<samtebbs>
Thanks :D
<samtebbs>
Memo to self, look at the section names properly next time
<FireFox317>
Hahah yup, I also see it right now XD
<samtebbs>
Other than them being ALLOC, other telling sign is that they are empty xD
<donaldallen>
samtebbs: extern is 'extern fn sqlite3_prepare_v2(db: *c_void, zSql: [*]const u8, nByte:c_int, ppStmt:**c_void, pzTail:**const u8) c_int;'. Call is 'sqlite3_prepare_v2(db, sql, -1, &result, null)'. Compiler complains: expected type '**const u8', found '(null)'.
<donaldallen>
samtebbs: I suppose I could lie to the compiler and define that parameter as a c_int in the extern. But given the stress on interoperability with C in zig, I'm guessing there's a less kludgy way to do this, a proper way.
TheLemonMan has joined #zig
<TheLemonMan>
donaldallen, you need a C pointer, normal pointers are non-nullable
<gonz_>
Which should be said, is more *proper*.
<donaldallen>
TheLemonMan: extern now 'extern fn sqlite3_prepare_v2(db: *c_void, zSql: [*]const u8, nByte:c_int, ppStmt:**c_void, pzTail:[*c]*const u8) c_int;'. Call the same. Compiler complains about the call: expected type '[*c]*const u8', found '(null)'.
<TheLemonMan>
uh, worksforme
<donaldallen>
TheLemonMan: Are you using 0.4.0?
<TheLemonMan>
nope, I only run master
<fengb>
Don't use 0.4.0. It's ancient
<donaldallen>
That's probably the issue. I installed 0.4.0 with the Arch package system. I'll give the latest from github a try. Thanks.
<TheLemonMan>
smh, isn't Arch supposed to only provide the latest and greatest version of everything?
<donaldallen>
Thanks all for the help earlier. It seems that things have gotten considerably better since 0.4.0. Still problems, though. I'll post an issue on github.
avoidr has joined #zig
kristoff_it has quit [Ping timeout: 240 seconds]
donaldallen has left #zig [#zig]
commander has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 240 seconds]
return0e has quit [Read error: Connection reset by peer]
FireFox317 has quit [Remote host closed the connection]
return0e has joined #zig
earnestly has quit [Ping timeout: 246 seconds]
earnestly has joined #zig
Akuli has quit [Quit: Leaving]
Ichorio has joined #zig
ky0ko has quit [Remote host closed the connection]
mahmudov has joined #zig
kristoff_it has joined #zig
wootehfoot has joined #zig
samtebbs has joined #zig
kristoff_it has quit [Ping timeout: 265 seconds]
<samtebbs>
hey andrewrk, when working on clashos, did you ever find that keeping the debug info in your binary made every section larger?
laaron has quit [Remote host closed the connection]
<samtebbs>
I'm running into a weird issue where following what you did in your stacktrace on panic blog makes every section almost 3 times as big
laaron has joined #zig
<waleee-cl>
Has there been some changes to zig fmt? It insists on removing any space between a struct name and the { for me
cheesy has joined #zig
<waleee-cl>
which doesn't seem to be the preferred format anywhere (in the docs, stdlib &c)
slice has quit [Ping timeout: 276 seconds]
return0e has quit [Ping timeout: 246 seconds]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
wootehfoot has quit [Read error: Connection reset by peer]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 265 seconds]
halosghost has quit [Quit: WeeChat 2.6]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 276 seconds]
Ichorio has quit [Ping timeout: 245 seconds]
<mikdusan>
hmmm i think we could benefit from having a 2 allocator "interfaces". today's interface is really about following 1:1 correlation between an alloc() and a free()
<mikdusan>
and the other being an alloc() only; ie: the free() is not in a 1:1 relationship
<mikdusan>
so then i can express in code that the code will not allow the latter statement: `const p = allocator.alloc(); defer allocator.free(p);`
<fengb>
There’s a proposal to make shrinkage optional
<fengb>
shrinkFn
<mikdusan>
yes for the implementation I suppose it goes from 2 fn down to 1 fn. but also strike destroy()
<mikdusan>
and strike free()
laaron has quit [Remote host closed the connection]
<mikdusan>
right now i am using a simple naming convention; have a struct that has 2 properties. one is named `heap` to be used 1-alloc,1-free; and other is named `arena` (needs better name) for alloc-only and code never calls arena.free()
<mikdusan>
pool is probably more generic than arena.
return0e has joined #zig
laaron has joined #zig
kristoff_it has joined #zig
samtebbs has quit [Quit: leaving]
kristoff_it has quit [Ping timeout: 246 seconds]
<stratact>
Actually is it safe to use a different allocator to free another allocator's allocation?