Hello!
First of all I would like to thank you everyone for your input. I really
appreciate it.
I would also like you to know that I managed to study the material that you
all have linked to (or that is generally available online on the project's
wikis of that matter) and I managed to come up with
Hi Fotis,
I finally found my changes made so far for gccgo on a computer suffering
double hard disk crashes. Hopefully most of the changes are available on
the backup I found. As it looks they were not too extensive. I'll send a
patch asap to the bug-hurd list, so you can continue from there (when
On 05/03/2013 12:11 PM, Paul Pluzhnikov wrote:
> On Fri, May 3, 2013 at 8:11 AM, Simon Richter wrote:
>
>> I'm writing a small preload library to trace pthread_* calls ...
>> In order to find the original function, I use dlsym(RTLD_NEXT, ...) ...
>
>> In any case, I am wondering if it is actuall
This is a revised version of the large store patch for ext2fs, written
by Ognyan Kulev. It provides support for stores larger than 2 GiB.
* ext2fs/balloc.c: Use the new disk_cache_block_ref and disk_cache_block_deref
functions to access blocks from the disk cache.
* ext2fs/ext2fs.c (main): Update
If requested by the user, make libpager call pager_notify_evict when a page
is flushed out by the kernel. Based on work by Ognyan Kulev.
* console/pager.c (pager_notify_evict): New function.
(user_pager_create): Update call to pager_create.
* ext2fs/pager.c: (pager_notify_evict): New function.
(cr
On Fri, May 3, 2013 at 8:11 AM, Simon Richter wrote:
> I'm writing a small preload library to trace pthread_* calls ...
> In order to find the original function, I use dlsym(RTLD_NEXT, ...) ...
> In any case, I am wondering if it is actually possible to redirect the
> pthread_* functions in this
Hi,
On 03.05.2013 17:17, Carlos O'Donell wrote:
> Can you produce a small self-contained test case that shows the
> expected versus observed behaviour?
Sure, attached.
I'm not entirely confident about expected behaviour -- the behaviour
observed on Hurd and BSD can be correct, and Linux the out
On 05/03/2013 11:11 AM, Simon Richter wrote:
> Hi,
>
> I'm writing a small preload library to trace pthread_* calls, and am
> running into a bit of a chicken-and-egg problem.
>
> In order to find the original function, I use dlsym(RTLD_NEXT, ...) to
> look up the symbol on the first invocation. O
Hi,
I'm writing a small preload library to trace pthread_* calls, and am
running into a bit of a chicken-and-egg problem.
In order to find the original function, I use dlsym(RTLD_NEXT, ...) to
look up the symbol on the first invocation. On Linux, this works find,
however on the Hurd and on FreeBS
Hi,
Alle venerdì 3 maggio 2013, 陆岳 ha scritto:
> --- a/gdb/configure.ac
> +++ b/gdb/configure.ac
> @@ -488,6 +488,15 @@ AC_CHECK_TOOL(WINDRES, windres)
>
> # Needed for GNU/Hurd.
> AC_CHECK_TOOL(MIG, mig)
> +case "${host}" in
> + *-linux*|*-k*bsd-gnu*)
> + ;;
> + i[[34
On 05/03/2013 09:28 AM, Thomas Schwinge wrote:
> Hmm, I think that instead of only examining the host system, $host, this
> also needs to examine the target system, $target. (Please tell if the
> difference between build, host, and target system is not clear to you.)
> The MIG tool is used to gene
> 陆岳 writes:
[…]
A few minor points.
> From 13d3edd1f6dbbc20b2801cea1fc367bf9042f977 Mon Sep 17 00:00:00 2001
> From: hacklu
> Date: Fri, 3 May 2013 18:27:08 +0800
> Subject: [PATCH] Patch check mig on GNU Hurd
> 2013-05-3 hacklu
There should be two spaces between
Hi!
thanks for your review.
On Fri, May 3, 2013 at 4:28 PM, Thomas Schwinge wrote:
>
> As GDB is a GNU project, instead of just a commit message it uses
> ChangeLog files. See the several ChangeLog files in the GDB sources. As
> your change only touches files in gdb/, only gdb/ChangeLog is rel
On Thu, 2013-05-02 at 23:52 +0200, Samuel Thibault wrote:
> Svante Signell, le Thu 02 May 2013 12:14:46 +0200, a écrit :
> > On Thu, 2013-05-02 at 01:47 +0200, Samuel Thibault wrote:
> But I guess you were still running the old kernel while doing this?
>
> You need to reboot with the new kernel t
Hi!
Adding the gdb-patches mailing list. While of course this is only
relevant for the GNU Hurd port of GDB, it will get committed to the GDB
source repository, so should be reviewed on the gdb-patches mailing list.
It is fine (and encouraged) to CC the bug-hurd mailing list for
Hurd-specific iss
hi,
I found that when you missing the mid under GNU Hurd, the GDB's
configure doesn't complain about that.
But you will get a compile error until you do the make.
So I add the check.
By the way, I just check the existence of mig, have not check whether
mig work correct yet.
This is my first time
16 matches
Mail list logo
