dpkg...
I: Unpacking e2fsprogs...
I: Unpacking findutils...
I: Unpacking gnumach-common...
I: Unpacking gnumach-image-1.8-486...
I: Unpacking grep...
I: Unpacking gzip...
I: Unpacking hostname...
I: Unpacking hurd...
I: Unpacking hurd-libs0.3:hurd-amd64...
I: Unpacking init-system-helpers...
I: Unpack
I have put some note on the wiki
https://darnassus.sceen.net/~hurd-web/open_issues/64-bit_port/
to build a proper debian hurd-amd64 chroot:
sudo debootstrap --foreign --verbose --arch hurd-amd64
--keyring=/usr/share/keyrings/debian-keyring.gpg sid chroot-hurd-amd64
https://people.debian.org
; clean_inlined_ports) and the MiG patch, which required a 3 line change
> > to add appropriate casts from mach_port_name_inlined_t* to mach_port_t*
> > in server.c.
>
> Thanks for the update!
>
> I confirm it now builds fine with -Werror, I have pushed the whole
> series.
Looks all fine, please push to master!
Samuel
Constantine Kousoulos, le Thu 08 Mar 2007 20:16:10 +0200, a écrit :
Since my notebook has a turion processor, shouldn't 'uname -m'
produce something like 'x86_64'?
No, because GNU Mach only supports AMD64 processors in 32bits mode.
Samuel
___
Bug
Arne Babenhauserheide, le Fri 23 Jul 2010 17:57:46 +0200, a écrit :
128MiB might be a bit too little… :)
Yes. At least 256MiB is a must.
(I don’t use kvm – I don’t know if my CPU supports it: no svm flag (amd64))
no svm on amd64 - no kvm (vmx on intel).
Samuel
Po Lu, le lun. 04 sept. 2023 08:53:21 +0800, a ecrit:
> Incidentally, where are the Debian hurd-amd64 images that are always in
> earshot but never in sight?
?
«
If people want to play with it, I have updated the image on
https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.
On 06 May 2023 16:17, Samuel Thibault wrote:
> This adds support for passing -m elf32_x86_64 vs -m elf_x86_64 to the
> linker on hurd-amd64
this was difficult to merge because you aren't using git.
please switch to that in the futrue when sending patches.
-mike
signature.asc
Descriptio
Hi,
Did anyone have any success in booting GNU/Hurd (GNUMach) on AMD64 computer? I
was playing with GNU/Hurd using Qemu, and it worked fine. Two days ago I have
found a forgotten 2.5G drive and I have installed hurd on that drive. But,
whenever I try to boot it, Grub just loads the kernel
On Wed, Apr 26, 2006 at 08:42:09PM +0200, Filip Brcic wrote:
Did anyone have any success in booting GNU/Hurd (GNUMach) on AMD64 computer?
I don't think so. I heard quite a number of people reporting the same
incident you just reported. Since I don't have such hardware, I can't
try to do
Sergey Bugaev, le mer. 03 mai 2023 01:16:29 +0300, a ecrit:
> I see [0] -- is that it? Cool!
>
> [0]: https://salsa.debian.org/glibc-team/glibc/-/commits/hurd-amd64
It's part of it yes.
> How does this work -- how does the Debian tooling know what
> 'hurd-amd64' means? I
Hi!
> This supports the x86_64-pc-gnu triplet
Applied. Thanks.
Salam-Shalom,
Werner
--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
openpgp-digital-signature.asc
Description: PGP signature
May 12, 2023 5:58 PM, "Samuel Thibault" wrote:
> I have put some note on the wiki
>
> https://darnassus.sceen.net/~hurd-web/open_issues/64-bit_port
>
> to build a proper debian hurd-amd64 chroot:
>
> sudo debootstrap --foreign --verbose --arch hurd-amd64
o "laptop" support then (albeit a little bit vintage, amd64
> uses newer expansion slots, but we don't support 64 bit...)
Amd64 cpus can boot 32bit systems fine. That works on my laptop for
instance.
Samuel
On September 4, 2023 9:50:34 AM GMT+02:00, Samuel Thibault
wrote:
>Po Lu, le lun. 04 sept. 2023 08:53:21 +0800, a ecrit:
>> Incidentally, where are the Debian hurd-amd64 images that are always in
>> earshot but never in sight?
>
>?
>
>«
>If people want to play wit
On 2/12/24 8:31 PM, Flavio Cruz wrote:
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs, including
Il 05/05/23 19:23, Samuel Thibault ha scritto:
Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit:
Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit:
On Fri, May 5, 2023 at 4:30 PM Samuel Thibault wrote:
FI, I'm having debian hurd-amd64 packages cross-built, I'm getting
Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit:
> Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit:
> > On Fri, May 5, 2023 at 4:30 PM Samuel Thibault
> > wrote:
> > > FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.g.
> &g
Samuel Thibault, le ven. 05 mai 2023 19:23:57 +0200, a ecrit:
> Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit:
> > Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit:
> > > On Fri, May 5, 2023 at 4:30 PM Samuel Thibault
> > > wrote:
> > >
On Fri, May 5, 2023 at 4:30 PM Samuel Thibault
> > > > wrote:
> > > > > FI, I'm having debian hurd-amd64 packages cross-built, I'm getting
> > > > > e.g.
> > > > > dash built, I'll probably have rumpkernel built too. Essential
On 2/23/24 9:28 PM, Flavio Cruz wrote:
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs
Constantine Kousoulos, le Mon 05 Mar 2007 20:37:25 +0200, a écrit :
I know that the amd64 arch is a big problem. Maybe with a little
help i could pinpoint some bugs and, maybe, fix them.
I wouldn't say so big a problem, since Mach got to boot fine :)
./native-install: line 138:16 Killed
This adds SIGSEGV_FAULT_STACKPOINTER for the hurd-amd64 case
--- ./lib/sigsegv.c.original2023-05-05 10:45:54.673751100 +
+++ ./lib/sigsegv.c 2023-05-05 10:48:47.903577554 +
@@ -351,6 +351,17 @@
"old esp, if trapped from user". */
# define SIGSEGV_FAULT_STACKPO
e.
> I've tried debootstrapping from
> https://people.debian.org/~sthibault/tmp/hurd-amd64 as the wiki page
> says; but that doesn't proceed beyond the rumpdisk. Rumpdisk just sits
> there, slowly spitting out logs;
Does it detect disks? What qemu parameters are you using?
I'm using a me
i386 and amd64,
the size of ptrdiff_t varies between the two.
It's unsigned long.
You might try unsharing the IRQ's for those devices, or some such. Or
compile a really utterly bare kernel.
In wichfile do I find the main() function for gnumah?
_start() in i386/i386at/boothdr.S.
You can also use the kernel debugger to help you out. See the manual
for details about it, it
, Filip Brcic
[EMAIL PROTECTED] wrote:Hi,Did anyone have any success in booting GNU/Hurd (GNUMach) on AMD64 computer? I
was playing with GNU/Hurd using Qemu, and it worked fine. Two days ago I havefound a forgotten 2.5G drive and I have installed hurd on that drive. But,whenever I try to boot
m
configuration files, relegating their task to Autoconf instead.
Incidentally, where are the Debian hurd-amd64 images that are always in
earshot but never in sight?
Thanks.
If people want to play with it, I have updated the image on
https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz
of course, since the second stage of debootstrap doesn't work yet,
nothing is configured, so you have to configure everything by hand to
get almost anything to work
Sergey Bugaev, le lun. 15 mai 2023 20:51:54 +0300, a ecrit:
> store (= rumpdisk, not ramdisk) and nano? :)
FI nano is now available as debian-amd64 package since a few days :)
Samuel
Hi,
Il 05/09/23 20:27, Guy-Fleury Iteriteka ha scritto:
https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz
»
And how you launch this one. I get: no bootable module
It can be used as a ramdisk; one way to use it (maybe not the simplest,
but more or less the one I used
Hi!
I've started porting gnumach to amd64, slowly, and I don't promise I'll
get anything ready soon, or ever.
I'm first going to fix compilation warnings on ia32 so that it's easier
to spot the 64-bit problems on amd64, and any regressions in ia32
introduced when fixing 64-bit problems.
I've
otableISO#Determine_those_options_which_need_to_be_adapted_on_amd64_or_i386
> ... and GNU Mach is not a Linux...
It seems that the Debian GNU/Hurd ISOs already use GRUB for booting via
legacy BIOS. So using GRUB for EFI would not be as inconvenient as for
Debian amd64, which needs configuration for both SYSLINUX and GRUB
that while int is 32 bits on both i386 and amd64, the
size of ptrdiff_t varies between the two.
It’s unsigned long.
Usually, ‘long’ requires %lX, not %X (‘int’.) These are both
32-bit on i386, but %lX is 64-bit on amd64 (as is ‘long’ there.)
AIUI, kern/printf.c /ignores
: src
status: broken
reasons:
-
missing:
pkg:
package: firefox-esr
version: 78.8.0esr-1
architecture: any,all
type: src
unsat-dependency: libnspr4-dev:hurd-i386 (>= 2:4.25~)
-
package: openjdk-11
version: 11.0.4+11-1
architec
Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit:
> Hello,
>
> On Fri, May 5, 2023 at 4:30 PM Samuel Thibault
> wrote:
> > FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.g.
> > dash built, I'll probably have rumpkernel built too. Es
On Sat, May 6, 2023 at 8:34 PM Samuel Thibault
wrote:
> This adds SIGSEGV_FAULT_STACKPOINTER for the hurd-amd64 case
>
> --- ./lib/sigsegv.c.original2023-05-05 10:45:54.673751100 +
> +++ ./lib/sigsegv.c 2023-05-05 10:48:47.903577554 +
> @@ -351,6 +351,17 @@
This adds support for passing -m elf32_x86_64 vs -m elf_x86_64 to the
linker on hurd-amd64
Changelog:
* m4/libtool.m4: dd x86_64-gnu* case to pass -m elf32_x86_64 vs
-m elf_x86_64 to linker.
--- m4/libtool.m4.orig 2023-05-03 18:33:23.949698403 +0200
+++ m4/libtool.m4 2023
Hello again, the bug report continues:
# uname -m
i386-AT386
Since my notebook has a turion processor, shouldn't 'uname -m'
produce something like 'x86_64'?
Uname seems to be buggy even when a non-amd processor is
concerned, as i have pointed out earlier
On Thu, 2009-12-17 at 23:42:37 +0100, Samuel Thibault wrote:
Looks all fine, please push to master!
Done, thanks!
I've removed the KERNEL_CS, and KERNEL_CS macros for the MACH_HYP case
in linux/src/include/asm-i386/segment.h when rebasing on top of master,
as those are handled already by way of
Guillem Jover, le Fri 18 Dec 2009 12:18:34 +0100, a écrit :
I've removed the KERNEL_CS, and KERNEL_CS macros for the MACH_HYP case
in linux/src/include/asm-i386/segment.h when rebasing on top of master,
as those are handled already by way of KERNEL_RING being set to 1 in
i386/i386/seg.h.
Ok,
On Tue, 2013-02-12 at 23:50 +0100, Samuel Thibault wrote:
Svante Signell, le Tue 12 Feb 2013 23:46:00 +0100, a écrit :
- some minor tweaks will still be made to be mor POSIX consistent.
It'd be way better to keep these as separate patches. That's how we'll
have to submit them to libc-alpha
On Fri, 2013-02-15 at 02:05 +0100, Samuel Thibault wrote:
BTW, I can understand the kind of frustration you can have of seeing
your work being thrown away and rewritten. Well, that's life,
software is a lot about frustration, you'll have to get a thick head.
As I said, it's no big deal from
4 :) (see master-x86_64 and port-amd64
branches)
What is missing is either a 64bit userland (very involved), or 64-32
conversion for Mach RPCs (complex). See list archives about that.
Samuel
Hi Samuel, hi,
Samuel Thibault - 25.10.23, 00:04:33 CEST:
> Some update on the 64bit port:
>
> - The debian-ports archive now has enough packages to bootstrap a
> chroot.
> - A 64bit debian buildd is getting set up, not much work is left there.
> - The hurd-amd64 wanna-bu
Flavio Cruz, le mer. 21 déc. 2022 16:06:32 -0500, a ecrit:
> On Wed, Dec 21, 2022 at 12:23:03PM +0100, Samuel Thibault wrote:
> > Also, could you perhaps Cc Helmut Grohne ? He will be
> > very interested in including the patches to prepare bootstrapping the
> > hurd
distinguish the
> two names, in the debugger and various other places.
Yes, but that is already the case for every other register that
existed as exxx on x86 and got extended to rxxx in amd64. This same
patch already replaces esi -> rsi, eip -> rip, eax -> rax etc. Why
single out eflags?
Sergey
Hello,
I continued stabbing at the network issue, it was just a size alignment
problem, so that depending on their sizes, half of the network packets
would be discarded by mach_msg. Hurd-amd64 packages are getting rebuilt
to contain the fix.
The issue I'm still seeing now is that I cannot get
Samuel Thibault, le mar. 08 août 2023 19:15:50 +0200, a ecrit:
> I continued stabbing at the network issue, it was just a size alignment
> problem, so that depending on their sizes, half of the network packets
> would be discarded by mach_msg. Hurd-amd64 packages are getting rebuilt
>
Hello,
On Fri, May 5, 2023 at 4:30 PM Samuel Thibault wrote:
> FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.g.
> dash built, I'll probably have rumpkernel built too. Essentially, we
> should be able to debootstrap a whole chroot.
Awesome!
Are these (binar
[0] is helpful (thank you!),
Note that it is just the boilerplate that I have in all my tmp/ repos.
> but I still have questions.
>
> [0]: https://people.debian.org/~sthibault/tmp/hurd-amd64/README.txt
>
> I can't just install packages by reconfiguring apt and installing the
tps://people.debian.org/~sthibault/tmp/hurd-amd64/README.txt
I can't just install packages by reconfiguring apt and installing them
directly as you suggest, because that assumes a working Debian
installation -- naturally, one for a different architecture, and one
that these new packages would break.
Maybe I'm suppo
and I'm loading the ext2fs.static module, as obtained from
https://people.debian.org/~sthibault/tmp/hurd-amd64/pool-hurd-amd64/h/hurd/hurd_0.9.git20230520-1_hurd-amd64.deb
which I have put on
https://dept-info.labri.fr/~thibault/tmp/ext2fs.static
and what I obtain is:
GNU Mach 1.8
ELF section
– I don’t know if my CPU supports it: no svm flag (amd64))
… I tried it now, but installation still stalls. Seems to need a bit more
testing from my side.
Best wishes,
Arne
--
Ich hab' nichts zu verbergen – hab ich gedacht:
- http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen
?)
...
Update: The problem seems to be hurd related not due to kvm.
FYI: I recently successfully compiled the failed ghc6.10.1+dfsg1-5 on a
Linux/amd64 box using the same toolchain as on GNU/Hurd.
(4 KiB/2
MiB/whatever amd64 allows)? (In case it'd make sense to support these at
some point?) Or is this over-engineering already?
These are virtual frames. And in any case, they are multiple of the base
page size. This interface is suitable for allocating large pages. It
would just require
numbers.
Good idea! But: what about differently sized frames (4 KiB/2
MiB/whatever amd64 allows)? (In case it'd make sense to support these at
some point?) Or is this over-engineering already?
These are virtual frames.
There are archs which have varying page size. I'd rather avoid
On Tue, 2013-01-22 at 19:15 +0100, Pino Toscano wrote:
Hi,
Alle martedì 22 gennaio 2013, Svante Signell ha scritto:
...
const int fd = (int) d[i].io_port;
- if (fd _hurd_dtablesize)
- {
d[i].cell = _hurd_dtable[fd];
On Tue, 2013-01-22 at 19:01 +0100, Samuel Thibault wrote:
Svante Signell, le Tue 22 Jan 2013 18:53:43 +0100, a écrit :
Attached is the first patch for a 3-way split of hurdselect.c into three
cases: DELAY, POLL, SELECT leading to a more POSIX conforming POLL.
It is way more readable that
On Tue, 2013-01-29 at 00:13 +0100, Samuel Thibault wrote:
Svante Signell, le Sun 20 Jan 2013 18:18:16 +0100, a écrit :
A recent problem popping up is that executables using the -pie flag when
linking segfaults when starting up. Examples are mktable in w3m
It doesn't seem so simple. I've
On Wed, 2013-02-13 at 10:38 +0100, Samuel Thibault wrote:
Svante Signell, le Wed 13 Feb 2013 10:22:37 +0100, a écrit :
On Wed, 2013-02-13 at 09:32 +0100, Samuel Thibault wrote:
Anyway, until next time no copyright assignment is needed...
If you consider working on libc again (and actually
On Fri, 2013-02-15 at 00:31 +0100, Samuel Thibault wrote:
Having a separate hurddoselect.c with a function containing the shared
code would have both factorization and hierarchy, but the semantic of
the function gets tricky, and it'd be easy to miss thing.
Select/poll *are* complex, you
[CCing bug-hurd]
I have done a number of attempts to boot Gnu/Hurd, but mostly the
computer interrupts and reboots in the middle of the process.
No idea if you checked this, but check if you have shared IRQ's. cat
/proc/interrupts in GNU/Linux or some such.
Partitions check: (DOS
Alfred M\. Szmidt [EMAIL PROTECTED] writes:
[Adding CC to bug-hurd, _again_, don't remove it!]
22: 9186 IO-APIC-level libata, NVidia CK804
23: 13705 IO-APIC-level libata, eth0
These two could cause problems, I don't know what libata or nvidia is.
But if GNU Mach
2006/4/29, Balaji Kutty [EMAIL PROTECTED]:
Hi all,I'm a newbie to Hurd. I have a Toshiba Satellite laptop with Intel centrino processor. I downloaded GNU/Hurd and configured my Grub. But, it doesn't boot. If I select this boot option it keeps rebooting.
Has anyone successfully booted Hurd in
versité de Kinshasa, DR Congo.
> > I would like to port the Mach microkernel to x64 architectures
>
> Well, it is already ported to x64 :) (see master-x86_64 and port-amd64
> branches)
>
> What is missing is either a 64bit userland (very involved), or 64-32
> conversion
ime.diff
> > src_libgo_build.diff
>
> Correction: five:
> add-gnu-to-libgo-headers.diff
And src_libgo_go_syscall.diff, eventually more. Best to use the complete set.
Regarding test suites the go test results are the same as for e.g. amd64:
This time the problem is with the symbol
vers under linux and
NetBSD. So "common stuff".
No help with Hurd - I installed the linux driver package.
One question: is the issue because the cards are behind PCMCIA/CardBus
and we don't support that?
Essentially no "laptop" support then (albeit a little bit vintage, amd64
uses
).
There is now: https://gitlab.com/procps-ng/procps/-/tags/v3.3.17rc1 released
Jan 22, 2021 (about 1 week ago).
Debian unstable is still based on 3.3.16: https://packages.debian.org/sid/procps
Paquet procps
sid (unstable) (admin): Utilitaires pour le système de fichiers /proc.
2:3.3.16-5: alpha amd64
On Tue, Oct 24, 2023 at 6:21 PM Samuel Thibault wrote:
>
> Some update on the 64bit port:
>
> - The debian-ports archive now has enough packages to bootstrap a
> chroot.
> - A 64bit debian buildd is getting set up, not much work is left there.
> - The hurd-amd64 wanna
into 64bit port addresses, this is not large enough.
I'm almost finished with building the base set of debian packages,
required to build & upload packages on the debian-ports archive (just
missing cmake that exposes some bootstrap bugs).
Before building the hurd-amd64 world, are we sure we are all
atches to prepare bootstrapping the
> hurd-amd64 Debian port :D
That would be great, but I think we still need the glibc bits too for a
complete bootstrap.
Sure, but we can progress alongside.
Samuel
FYI merged as
http://sourceware.org/git/?p=binutils-gdb.git;a
gt; Also, could you perhaps Cc Helmut Grohne ? He will be
> > > > very interested in including the patches to prepare bootstrapping the
> > > > hurd-amd64 Debian port :D
> > >
> > > That would be great, but I think we still need the glibc bits too for
* Actually int es, ds. */
> +# define REG_ESDSREG_ESDS
On second thought, why REG_ESDS? They are basically useless on amd64
Linux packs all segment registers in REG_CSGSFS, probably better to
stuff them the same way? (all three really are 16bit only, even if the
thread_state is padding them to 32bits).
Samuel
Hello,
I guess this is where I ask (consistent with the subject line) about
how I would run the x86_64 system (to reproduce & debug this).
I've tried debootstrapping from
https://people.debian.org/~sthibault/tmp/hurd-amd64 as the wiki page
says; but that doesn't proceed beyond the rump
Hello,
I'm still stuck without being able to start packages building for
hurd-amd64 due to this unreliability.
Sergey Bugaev, le mar. 31 oct. 2023 10:09:17 +0300, a ecrit:
> On Mon, Oct 30, 2023 at 1:27 AM Samuel Thibault
> wrote:
> > time while [ "$(echo -n `echo a` )&quo
Luca, le mer. 03 janv. 2024 20:07:00 +0100, a ecrit:
> Il 03/01/24 09:17, Sergey Bugaev ha scritto:
> > How are you running it? Should I still be using a ramdisk image and
> > not rumpdisk?
>
> Recently I've been installing hurd-amd64 on another disk of my hurd-i386
Samuel Thibault wrote:
Constantine Kousoulos, le Mon 05 Mar 2007 20:37:25 +0200, a ιcrit :
I know that the amd64 arch is a big problem. Maybe with a little
help i could pinpoint some bugs and, maybe, fix them.
I wouldn't say so big a problem, since Mach got to boot fine :)
:)
./native
Interesting packages: zsh, bind9, syslog-ng, wodim, smbclient,
pulseaudio*, gnome-keyring, ntpdate, etc.
A lot of which *already* have [linux-any] or [!hurd-i386 !kfreebsd-i386
!kfreebsd-amd64] or | not+linux-gnu in the dependency (the former is the
preferred form). Better use
grep-aptavail
report:
-
package: 0ad
version: 0.0.23.1-5
architecture: amd64,arm64,armhf,i386,kfreebsd-amd64,kfreebsd-i386
type: src
status: broken
reasons:
-
missing:
pkg:
package: init-system-helpers
version: 1.60
architecture: all
essential: true
unsat
> source-packages: 32570
> broken-packages: 32570
> paul@binou:~$
>
> The reason:
> output-version: 1.2
> native-architecture: i386
> host-architecture: i386
> report:
> -
> package: 0ad
> version: 0.0.23.1-5
> architecture: amd64,arm64,armhf,i386,kfree
Sergey Bugaev, le ven. 21 avril 2023 17:30:12 +0300, a ecrit:
> On Fri, Apr 21, 2023 at 12:24 PM Samuel Thibault
> wrote:
> > No, they don't :) otherwise they wouldn't respect the ABI. The AMD64
> > ABI indeed defaults to /lib/ld64.so.1, and says that Linux uses
> > /li
On Fri, Apr 21, 2023 at 12:24 PM Samuel Thibault
wrote:
> No, they don't :) otherwise they wouldn't respect the ABI. The AMD64
> ABI indeed defaults to /lib/ld64.so.1, and says that Linux uses
> /lib64/ld-linux-x86-64.so.2, and that is cast in stone, we cannot change
> it any more.
> ((struct i386_exception_link *)STACK_IKS(stack) - 1)
> >
> > +#ifdef __x86_64__
> > +#ifdef USER32
> > +#define STACK_ALIGN 4
> > +#else
> > +/* Follow System V AMD64 ABI guidelines. */
> > +#define STACK_ALIGN 16
> > +#en
meant bootstrap as in servers bootstrap, bootstrapfs, all
that. Getting Hurd proper to run on x86_64 *is* the most interesting
thing right now, which is why I'm doing it :)
I see [0] -- is that it? Cool!
[0]: https://salsa.debian.org/glibc-team/glibc/-/commits/hurd-amd64
How does this work -- how
Luca writes:
> Hi Sergey,
>
> Il 03/01/24 09:17, Sergey Bugaev ha scritto:
>> How are you running it? Should I still be using a ramdisk image and
>> not rumpdisk?
>
> Recently I've been installing hurd-amd64 on another disk of my
> hurd-i386 vm and booting from that
ts
as they go.
> On Sun, May 28, 2023 at 5:20 AM Samuel Thibault
> wrote:
> > If people want to play with it, I have updated the image on
> >
> > https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz
> >
> > of course, since the second stage of de
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs, including
i386_thread_state. The signal code
isting code whenever it makes sense.
>
> * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
> position of amd64 registers in the different Hurd structs, including
> i386_thread_state. The signal code is very similar to i686, except the
> trampoline code is adapt
loaded fixed
packages to debian-ports, to be available within a few hours. Samuel Flavio
Cruz, le jeu. 15 févr. 2024 01:56:14 -0500, a ecrit: > This port extends the
existing i686 port to support x86_64 by trying to > reuse existing code
whenever it makes sense. > > * gdb/amd64-gnu-
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs, including
i386_thread_state. The signal code
ing to
> reuse existing code whenever it makes sense.
>
> * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
> position of amd64 registers in the different Hurd structs, including
> i386_thread_state. The signal code is very similar to i686, except the
> tramp
It works on amd processors, only not on amd64 ones.
On Sun, 27 Aug 2006 20:38:41 +0300
Constantine Kousoulos [EMAIL PROTECTED] wrote:
Hello Balaji,
These are good places to look for information (i'm sure you've
already found them):
http://www.gnu.org/software/hurd/
http
when I had to update
my wifes update after a few months.
My reaction back then was to say well, then I'll wait till the transition
path to xz-utils is clear. For amd64 that's already the case, but for
ppc it wasn't and I'm not sure that it is now.
I think the reason for the problems
frame numbers.
Good idea! But: what about differently sized frames (4 KiB/2
MiB/whatever amd64 allows)? (In case it'd make sense to support these at
some point?) Or is this over-engineering already?
Grüße,
Thomas
pgpTtOACGU65b.pgp
Description: PGP signature
On Tue, 2013-02-12 at 23:52 +0100, Pino Toscano wrote:
Alle martedì 12 febbraio 2013, Svante Signell ha scritto:
* change the FD_SETSIZE upper value check to larger than or equal
from larger than.
(from POSIX definition of select:
On Wed, 2013-02-13 at 09:32 +0100, Samuel Thibault wrote:
(I will reply on the other items this evening)
Svante Signell, le Wed 13 Feb 2013 06:51:29 +0100, a écrit :
- you cannot commit this code unless I agree to sign the copyright
papers for libc (which I of course will when asked for).
On Fri, 2013-02-15 at 00:31 +0100, Samuel Thibault wrote:
Svante Signell, le Fri 15 Feb 2013 00:18:16 +0100, a écrit :
I don't understand what you mean. What delay are you talking about?
The only delay in by branch is the delay requested by the user.
Well, with my code I need a
On Fri, 2013-02-15 at 19:59 +0100, Samuel Thibault wrote:
Svante Signell, le Fri 15 Feb 2013 10:54:44 +0100, a écrit :
So it's ii-1 whose array position gets _hurd_port_free()d. array
position ii does *not* get _hurd_port_free()d, while
/* If one descriptor is bogus, mark
? or
is it ptrdiff_t? ¹), I’d rather like to see casts to /int/ here,
as it’s what %X (usually – no idea about vm/*) implies.
¹ Please note that while int is 32 bits on both i386 and amd64,
the size of ptrdiff_t varies between the two.
[…]
--
FSF associate member #7257
1 - 100 of 216 matches
Mail list logo
