[PATCH v3] Port GDB to Hurd x86_64.

This port extends the existing i686 port to support x86_64 by reusing 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. The signal code is very similar to i686, except the

Re: Debug into glibc with source code display in gdb on Debian

.c: No such file or directory. > > > > ``` > > > > > > > > I expected it will show me the source code of hurdselect.c. > > > > > > You need to download it with `apt source glibc` and cd into it, > > > otherwise gdb can't magically

Re: Debug into glibc with source code display in gdb on Debian

ow me the source code of hurdselect.c. > > > > You need to download it with `apt source glibc` and cd into it, > > otherwise gdb can't magically invent it :) > > But I invoked the gdb using the following command in $(curl-src)/tests/: > > ``` > ~/curl/tests$ ./runtests.pl 546 -g > ``` You can use set directories /where/you/put/glibc Samuel

Re: Debug into glibc with source code display in gdb on Debian

> timeout=0x103cba4, sigmask=0x0) at ./hurd/hurdselect.c:51 > > 51 ./hurd/hurdselect.c: No such file or directory. > > ``` > > > > I expected it will show me the source code of hurdselect.c. > > You need to download it with `apt source glibc` and cd into it, &g

Re: Debug into glibc with source code display in gdb on Debian

lect.c: No such file or directory. > ``` > > I expected it will show me the source code of hurdselect.c. You need to download it with `apt source glibc` and cd into it, otherwise gdb can't magically invent it :) Samuel

Debug into glibc with source code display in gdb on Debian

Hi, I'm trying to track the curl failed tests by debugging select() function (or system call?) defined in glibc using gdb. When I executed `b _hurd_select` to set a break point and run the program. The gdb stopped at the breakpoint but it gives me the following info: ``` Thread 2 hit Break

Re: SOLVELD [cross] building gdb for the 64bit Hurd?

jann...@gnu.org, le ven. 15 nov. 2024 11:14:39 +0100, a ecrit: > One other thing that puzzles me is that unless I explicitly configure with > > --enable-targets=i586-pc-gnu,x86_64-pc-gnu" > > (note that i586-pc-gnu _must_ be present), the [cross-]built gdb doesn't &

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

r-msg-clobber.diff> >> >> for gdb to work again? > > It can't hurt at least. Hehe :) It does better than that, I can confirm that using this patch gdb works again! \o/ Greetings, Janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

jann...@gnu.org, le dim. 17 nov. 2024 21:17:18 +0100, a ecrit: > Or could it be that I also need > > > <https://salsa.debian.org/glibc-team/glibc/-/blob/027f94215a633cbf53794d4b48675fde36706e35/debian/patches/hurd-i386/local-intr-msg-clobber.diff> > > for gdb to wo

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

ls, basically git-intr-msg-clobber.diff is really a requirement, >> otherwise e.g. $() shell replacement don't work properly. Hmm. I found that using git-intr-msg-clobber.diff, gdb no longer works for me, I get: --8<---cut here---start->8--- Curren

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

On November 16, 2024 10:13:22 PM GMT+02:00, Samuel Thibault wrote: >jann...@gnu.org, le sam. 16 nov. 2024 20:47:40 +0100, a ecrit: >> Samuel Thibault writes: >> >> > jann...@gnu.org, le sam. 16 nov. 2024 17:33:08 +0100, a ecrit: >> >> >> Okay, so Guix hasn't been using >> >> >> >>

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

Samuel Thibault writes: > jann...@gnu.org, le sam. 16 nov. 2024 20:47:40 +0100, a ecrit: >> Samuel Thibault writes: >> >> > jann...@gnu.org, le sam. 16 nov. 2024 17:33:08 +0100, a ecrit: >> >> >> Okay, so Guix hasn't been using >> >> >> >>

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

jann...@gnu.org, le sam. 16 nov. 2024 20:47:40 +0100, a ecrit: > Samuel Thibault writes: > > > jann...@gnu.org, le sam. 16 nov. 2024 17:33:08 +0100, a ecrit: > > >> Okay, so Guix hasn't been using > >> > >>

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

Samuel Thibault writes: Hi! > jann...@gnu.org, le sam. 16 nov. 2024 17:33:08 +0100, a ecrit: >> Okay, so Guix hasn't been using >> >> >>

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

Hello, jann...@gnu.org, le sam. 16 nov. 2024 17:33:08 +0100, a ecrit: > #if defined _LIBC > /* We do not want this call to be cut short by a thread > cancellation. Therefore disable cancellation for now. */ > int state = PTHREAD_CANCEL_ENABLE; > __pthread_setcancelstate (PTHREAD_CANCE

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

27;t see why it would entail a crash. Again, actual asm would be > enlightening. The attached gdb log clearly shows the problem: --8<---cut here---start->8--- => 0x0042efe8 <__error_internal+40>:e8 13 10 bd ff call 0x0 (gdb) s

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

ile it? I failed to get a hang after switching to #if 0 > It turns out that, although there is a gnulib gnu/error.c distributed, > it is not being compiled. Ah, that's possible. And gdb pointing to it can just be gdb getting confused. You can check the value of GL_COND_OBJ_

static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

34, which is inside "#if _LIBC" code. > > In your log it's "if (res != len)" that segfaults. But with > optimizations, it's hard for gdb to provide correct information, better > switch to asm. So, I took another approach. I minimized the tar archive, keep

Re: SOLVELD [cross] building gdb for the 64bit Hurd?

=0, errnum=0, message=0x5aff78 > "Option %s: Treating date '%s' as %s") at error.c:274 > 274 vfprintf (stderr, message, args); > (gdb) p stderr > $6 = (FILE *) 0x608400 <_IO_2_1_stderr_> > (gdb) p message > $7 = 0x5aff78 "Option %s: Treating

Re: SOLVELD [cross] building gdb for the 64bit Hurd?

Samuel Thibault writes: Hi! > jann...@gnu.org, le ven. 15 nov. 2024 11:14:39 +0100, a ecrit: >> As a corollary, using this GDB I found that the statically built tar >> segfaults on the vtrying to issue the >> >>tar: Option --mtime: Treating date '@1'

Re: SOLVELD [cross] building gdb for the 64bit Hurd?

Hello, jann...@gnu.org, le ven. 15 nov. 2024 11:14:39 +0100, a ecrit: > As a corollary, using this GDB I found that the statically built tar > segfaults on the vtrying to issue the > >tar: Option --mtime: Treating date '@1' as 1970-01-01 01:00:01 > > warning

SOLVELD [cross] building gdb for the 64bit Hurd?

Flávio Cruz writes: Hello Flávio, >> On Thu, Nov 14, 2024 at 12:44 PM wrote: >> >> I'm trying to build gdb-15.2 for the 64bit Hurd using this patch >> >> <https://lists.gnu.org/archive/html/bug-hurd/2024-07/msg1.html> [..] > I bel

Re: [cross] building gdb for the 64bit Hurd?

Hi Janneke On Thu, Nov 14, 2024 at 12:44 PM wrote: > Hi! > > I'm trying to build gdb-15.2 for the 64bit Hurd using this patch > > <https://lists.gnu.org/archive/html/bug-hurd/2024-07/msg1.html> > > Some context: Although the Guix 64bit Hurd now boots (

[cross] building gdb for the 64bit Hurd?

Hi! I'm trying to build gdb-15.2 for the 64bit Hurd using this patch <https://lists.gnu.org/archive/html/bug-hurd/2024-07/msg1.html> Some context: Although the Guix 64bit Hurd now boots (yay!), a statically linked tar hangs when invoked with "--mtime=@1", so

Re: Unprivileged double fault with GDB and simple program written in assembly

Hi, Il 08/09/24 01:23, Samuel Thibault ha scritto: Hello, AIUI, the fix you submitted was meant to fix this? yes, at least to correctly decode the registers in the fault handler, I didn't look deeper yet. Luca

Re: Unprivileged double fault with GDB and simple program written in assembly

02ff8' > > `panic ../i386/i386/trap.c:677: handle_double_fault: DOUBLE FAULT! This is > > critical' > > I can reproduce the issues, both with and without gdb; in particular, I see > that there is a bug in decoding the registers after a double fault; Fixing

Re: Unprivileged double fault with GDB and simple program written in assembly

error, error 01402ff8' `panic ../i386/i386/trap.c:677: handle_double_fault: DOUBLE FAULT! This is critical' I can reproduce the issues, both with and without gdb; in particular, I see that there is a bug in decoding the registers after a double fault; Fixing that I see RAX 00

Unprivileged double fault with GDB and simple program written in assembly

MSG_Hello: .ascii "Hello, world!\n" .set LEN_Hello, . - MSG_Hello I built the program and ran it like so: $ as -g program.S -o prorgam.o $ ld -g program.o -o program $ gdb program (gdb) break start (gdb) run (gdb) next 5 At this point, a double fault evidently happens, Mach starts pani

Re: [PATCH v2] Port GDB to Hurd x86_64.

On Tue, Feb 27, 2024 at 11:15 PM John Baldwin wrote: > 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

[PATCH v2] Port GDB to Hurd x86_64.

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. The signal code is very similar to i686, except the

Re: [PATCH v2] Port GDB to Hurd x86_64.

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. The

[PATCH v2] Port GDB to Hurd x86_64.

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. The signal code is very similar to i686, except the

Re: [PATCH] Port GDB to Hurd x86_64.

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

Re: [PATCH v2] Port GDB to Hurd x86_64.

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-

Re: [PATCH v2] Port GDB to Hurd x86_64.

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

[PATCH v2] Port GDB to Hurd x86_64.

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 is

Re: [PATCH] Port GDB to Hurd x86_64.

FI, I have uploaded updated gdb packages to debian-ports. I noticed that we get warnings about libraries and the backtrace indeed gets wrong in libraries, so that probably needs some more fixes. Samuel Flavio Cruz, le lun. 12 févr. 2024 23:31:00 -0500, a ecrit: > This port extends the exist

[PATCH] Port GDB to Hurd x86_64.

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 is

Re: [PATCH binutils-gdb] Port GDB to Hurd x86_64.

Flávio Cruz, le ven. 09 févr. 2024 00:45:05 -0500, a ecrit: > I did a few more tests and GDB seems to recognize the signal handler frame > correctly when backtracking > and listing the frames during a signal. Good :) > Let me know if there's other ways to confirm this is wo

Re: [PATCH binutils-gdb] Port GDB to Hurd x86_64.

ll the slot for the address for __sigreturn to return to, and a copy of SCP for __sigreturn's argument. Load the SCP as for a call, and "return" to calling __sigreturn (SCP); this call never returns. */ So I think this part should be changed to just read_memor

Re: [PATCH binutils-gdb] Port GDB to Hurd x86_64.

Flavio Cruz, le dim. 04 févr. 2024 01:43:48 -0500, a ecrit: > +/* Recognizing signal handler frames. */ > + > +/* When the GNU/Hurd libc calls a signal handler, the return address points > + inside the trampoline assembly snippet. > + > + If the trampoline function name can not be identified,

Re: [PATCH binutils-gdb] Port GDB to Hurd x86_64.

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

[PATCH binutils-gdb] Port GDB to Hurd x86_64.

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 is

Re: GDB breakpoints are broken in new threads -- here's why

; would fetch the previous one, and if it's non-null, it will perform a > > > special synchronous RPC on it, both passing the new exception port > > > that it would set to the tracer (so there's no need to actually set > > > it), and telling the tracer what its

Re: GDB breakpoints are broken in new threads -- here's why

special synchronous RPC on it, both passing the new exception port > > that it would set to the tracer (so there's no need to actually set > > it), and telling the tracer what its signal thread is (currently GDB > > just tries to guess that the second thread is the one, exc

Re: GDB breakpoints are broken in new threads -- here's why

gt; that it would set to the tracer (so there's no need to actually set > it), and telling the tracer what its signal thread is (currently GDB > just tries to guess that the second thread is the one, except this > again doesn't work for the very same reason, there's not yet

[bug #29642] gdb: breakpoints in triggered in other threads result in SIGTRAP

Update of bug #29642 (project hurd): Wiki-like text discussion box: => Sergey worked on the issue: https://lists.gnu.org/archive/html/bug-hurd/2023-04/msg3.html ___ Reply to this item at:

GDB breakpoints are broken in new threads -- here's why

matching RPC, GDB insists that the *main* thread has received SIGTRAP, and refuses to let the program run any further (no matter how much I ask it with 'next', 'continue', 'signal 0', etc). If I look into the threads' states ('info thread', 'thread

gdb fixed

Hello, Some chat on IRC mentioned an upstream fix for the "inferior" bug in gdb. I have applied the fix on the debian-ports package, it seems to be working! Samuel

[gdb, hurd] Adjust to Hurd "proc" interface changes (was: proc_task2proc prototype change)

Hi! On Tue, 06 Jun 2017 08:49:16 +0200, Justus Winter wrote: > David Michael writes: > > On Mon, Jun 5, 2017 at 7:40 AM, Justus Winter wrote: > >> [...] > > The reply > > functions still have mach_port_poly_t, though, and they are used by > > GDB. Is tha

Re: Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

Ping On Wed, 2017-12-27 at 23:36 +0100, Svante Signell wrote: > On Tue, 2017-12-26 at 09:40 +0100, Héctor Orón Martínez wrote: > > Hello Svante, > > > > On Sat, Dec 23, 2017 at 7:41 PM, Svante Signell > > wrote: > > > Hello, > > > > > > These patches was submitted to Debian November 13 2017. No

Re: Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

On Tue, 2017-12-26 at 09:40 +0100, Héctor Orón Martínez wrote: > Hello Svante, > > On Sat, Dec 23, 2017 at 7:41 PM, Svante Signell > wrote: > > Hello, > > > > These patches was submitted to Debian November 13 2017. Nothing has > > happened so far, so maybe upstream would be interested to conside

Re: Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

age -- > From: Svante Signell > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Mon, 13 Nov 2017 04:31:34 +0100 > Subject: gdb: FTBFS on hurd-i386 > Source: gdb > Version: 8.0-1 > Severity: important > Tags: patch > User: debian-h...@lists.debian.org > User

[Fwd: gdb: FTBFS on hurd-i386]

Hello, These patches was submitted to Debian November 13 2017. Nothing has happened so far, so maybe upstream would be interested to consider the patches for next release. Thanks! --- Begin Message --- Source: gdb Version: 8.0-1 Severity: important Tags: patch User: debian-h...@lists.debian.org

Re: gdb and PIE binaries

Hello, Roland McGrath, on ven. 11 nov. 2016 14:57:21 -0800, wrote: > On the Hurd, we don't really have auxv at all. But to simplify things > with GDB, we could have our core dumps include an NT_AUXV containing > just an AT_ENTRY value synthesized by other means. Off hand I

Re: gdb handling of Mach exceptions

"Brent W. Baccala" writes: > On Wed, Nov 23, 2016 at 10:03 PM, Brent W. Baccala > wrote: > >> >> Any comments? >> > > Well, yes, actually. :-) > > gdb's hurd target has a poorly documented command "set noninvasive". I > don&#

Re: gdb handling of Mach exceptions

On Wed, Nov 23, 2016 at 10:03 PM, Brent W. Baccala wrote: > > Any comments? > Well, yes, actually. :-) gdb's hurd target has a poorly documented command "set noninvasive". I don't completely understand it, but... I'm starting to see the rational for an "invasive" debugging mode. "Invasive" m

Re: gdb handling of Mach exceptions

On Wed, 2016-11-23 at 22:03 -1000, Brent W. Baccala wrote: > Hi - > > I've been working with gdb on the test programs that Samuel posted to > test signal preemptors. > > It seems that gdb doesn't reliably intercept the task's exception > port.  It intercept

Re: gdb handling of Mach exceptions

Hi - I've been working with gdb on the test programs that Samuel posted to test signal preemptors. It seems that gdb doesn't reliably intercept the task's exception port. It intercepts it once, when it creates the child process, but then assumes that it doesn't change. Som

Re: gdb and PIE binaries

Brent W. Baccala, on Tue 22 Nov 2016 16:06:18 -1000, wrote: > The Debian /usr/bin/ > gdb, though, is not PIE, which makes me wonder if someone (Samuel?) is > compiling our Debian packages without PIE, to avoid this problem. PIE has been systematically been enabled in Debian only rece

Re: gdb and PIE binaries

On Fri, Nov 11, 2016 at 7:17 AM, Samuel Thibault wrote: > Hello, > > Debian is pushing more and more PIE builds, so that address > randomization can be done. However, on GNU/Hurd, gdb can't work with > core files from processes running PIE programs, so one has to pass > CF

[Bug gdb/20851] New: Mach-specific exceptions aren't caught correctly

https://sourceware.org/bugzilla/show_bug.cgi?id=20851 Bug ID: 20851 Summary: Mach-specific exceptions aren't caught correctly Product: gdb Version: 7.10 Status: UNCONFIRMED Severity: normal Priorit

Re: gdb handling of Mach exceptions

Hello, Brent W. Baccala, on Sun 20 Nov 2016 22:03:51 -1000, wrote: > Obviously, tacking a Mach-specific include into signals.c isn't the right > solution, so can somebody suggest a proper fix? Better ask a gdb list :) Samuel

gdb handling of Mach exceptions

Hi - I've been trying to use gdb on ext2fs when it runs out of disk space and starts generating memory access exceptions. It doesn't behave right. The memory faults get reported as unknown signals and the program can't be restarted: Program received signal ?, Unknown signal

Re: gdb and PIE binaries

AFAIK gdb does not use fancy information like file-mapping stuff. NT_FILE is probably hard to support on the Hurd, since we don't have a way to go backwards from a memory object port to a file (let alone a file name). All GDB needs is to know where the PIE was loaded, so it can find the DT_

Re: gdb and PIE binaries

Samuel Thibault, on Fri 11 Nov 2016 18:17:43 +0100, wrote: > AIUI, what gdb misses is simply the name of the files being mapped: > since the mappings may be random, it can't invent the file names. I forgot to mention: on Linux, its provided in the core file through an NT_FILE note. Samuel

gdb and PIE binaries

Hello, Debian is pushing more and more PIE builds, so that address randomization can be done. However, on GNU/Hurd, gdb can't work with core files from processes running PIE programs, so one has to pass CFLAGS=-no-pie etc. to be able to debug programs, it'll become more and more p

Hurd: Make gdb/reply_mig_hack.awk script compatible to "mawk" (was: [RFC] GDB Hurd Fixes)

Hi! On Mon, 6 Jan 2014 17:56:27 +0100, I wrote: > On Fri, 20 Sep 2013 11:17:08 -0400, David Michael > wrote: > > mig has stopped using the "auto" keyword in its output.[1] > > Without that keyword, gdb/reply_mig_hack.awk fails to match a > > neces

Re: GDB testsuite: »Memory at address 0 is possibly executable«

Richard Braun, le Sat 13 Sep 2014 10:13:48 +0200, a écrit : > (with the interesting addition that, if MAP_FIXED isn't set, > but the hint is non-zero, the returned mapping must not start at > address 0). Well, it's not easy to implement this, since vm_map is generic, and could be used for other ki

Re: GDB testsuite: »Memory at address 0 is possibly executable«

On Sat, Sep 13, 2014 at 01:39:05AM +0200, Samuel Thibault wrote: > So it seems we need what is not actually documented, i.e. a vm_map > with anywhere=1, but which takes into account the suggested address. > I'm fine with officially supporting that, we just need to fix the > documentation, and fix a

Re: GDB testsuite: »Memory at address 0 is possibly executable«

Samuel Thibault, le Sat 13 Sep 2014 09:54:56 +0200, a écrit : > I've dug a bit more, glibc's _hurd_startup reserves page 0, so no vm_map > or vm_allocate call should be allocating at address 0. But with the > change, address 0 is already taken by the first mapped binary, ld.so. I > guess exec needs

Re: GDB testsuite: »Memory at address 0 is possibly executable«

Justus Winter, le Sat 13 Sep 2014 02:40:17 +0200, a écrit : > Quoting Samuel Thibault (2014-09-13 01:39:05) > > So it seems we need what is not actually documented, i.e. a vm_map > > with anywhere=1, but which takes into account the suggested address. > > I'm fine with officially supporting that, w

Re: GDB testsuite: »Memory at address 0 is possibly executable«

Quoting Samuel Thibault (2014-09-13 01:39:05) > So it seems we need what is not actually documented, i.e. a vm_map > with anywhere=1, but which takes into account the suggested address. > I'm fine with officially supporting that, we just need to fix the > documentation, I'm sorry, I'm lost. What

Re: GDB testsuite: »Memory at address 0 is possibly executable«

(Just to be clear: I don't think the fix proposed by Justus initially is correct: it was essentially making applications with random addresses actually get to have their map done starting from address 0, but we really ought to rather fix their randomness directly) Samuel

Re: GDB testsuite: »Memory at address 0 is possibly executable«

Mmm. So it seems we need what is not actually documented, i.e. a vm_map with anywhere=1, but which takes into account the suggested address. I'm fine with officially supporting that, we just need to fix the documentation, and fix all places which weren't aware of this behavior (there are very few)

Re: GDB testsuite: »Memory at address 0 is possibly executable«

Hi :) Quoting Thomas Schwinge (2014-09-11 16:23:04) > $ ldd /bin/true > libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x0103a000) > /lib/ld.so => /lib/ld.so.1 (0x) > libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x011fa000) > libhurduse

GDB testsuite: »Memory at address 0 is possibly executable«

Hi! I've noticed that you guys have recently done some changes in GNU Mach's vm_map or thereabouts, and -- I presume -- that is affecting the GDB testsuite in that tests that used to PASS are now no longer considered for execution, because »Memory at address 0 is possibly executable«:

Re: [RFC] GDB Hurd Fixes

Hi! On Mon, 5 May 2014 23:49:33 -0400, Samuel Bronson wrote: > On 1/6/14, Thomas Schwinge wrote: > > Sorry for the delay, and thanks for the patches you posted. Here are > > three patches, based on yours, that I intend to apply if there are no > > further comments. > > What happened to applyin

Re: [RFC] GDB Hurd Fixes

On 1/6/14, Thomas Schwinge wrote: > Hi! > > Sorry for the delay, and thanks for the patches you posted. Here are > three patches, based on yours, that I intend to apply if there are no > further comments. What happened to applying these? (I'd like to cherrypick them for the Debian package.)

Re: GDB: "warning: Can't wait for pid ???: No child processes"

the > current upstream master branch. > I'm not very optimistic about this things, I found some redundant files. Gdb was very care by many developers, that's maybe not allowed to check in if we can't remove these redundant files . I think gdbserver is very important for debug

Re: GDB: "warning: Can't wait for pid ???: No child processes"

Hi! On Fri, 11 Apr 2014 20:18:19 +0800, Zhang Cong wrote: > On Wed, Apr 9, 2014 at 8:57 PM, Yue Lu wrote: > So, The question left is why the code was not merge to upstream, And if it > can do, many hurder will thank you. > > The upstream reject your patch? Not at all. It "just" needs to be

Re: GDB: "warning: Can't wait for pid ???: No child processes" (was: GNU accepted as a mentoring organization in GSOC 2014)

Hi, On Wed, Apr 9, 2014 at 8:57 PM, Yue Lu wrote: > > > > The reason is that the native _GDB_ doesn't work either on Hurd. So as > gdbserver. You can try to attach to a exist process by GDB, you will get > that warnning. In detail, there is no distinct difference between

Re: GDB: "warning: Can't wait for pid ???: No child processes" (was: GNU accepted as a mentoring organization in GSOC 2014)

Hi! On Tue, Apr 8, 2014 at 11:26 PM, Zhang Cong wrote: > Why, I can't understand ? the gdb server be the debugged program's > parent, right? > And gdb just interactive with gdb server and gdbserver interactive with > the debugged program, right? > > Yes, if you us

Re: GDB: "warning: Can't wait for pid ???: No child processes" (was: GNU accepted as a mentoring organization in GSOC 2014)

On Tue, Apr 8, 2014 at 11:00 PM, Hacklu wrote: I am sorry to say that, when use gdb server you also need to re-parent > process. Because when I implement gdb server on Hurd, I found there is a > limit on Hurd when you attach to a process you can't resume the process > from stop

Re: GDB: "warning: Can't wait for pid ???: No child processes" (was: GNU accepted as a mentoring organization in GSOC 2014)

Hi! Zhang Cong wrote: > Hi Thomas, > >I want to make uim-fep ( https://code.google.com/p/uim/wiki/UimFep ) work > with hurd, it a front end processer, it's not work and I try to debug it. > >Because the program itself need hook the input and output, s

Re: GDB: "warning: Can't wait for pid ???: No child processes" (was: GNU accepted as a mentoring organization in GSOC 2014)

Hi Thomas, I want to make uim-fep ( https://code.google.com/p/uim/wiki/UimFep ) work with hurd, it a front end processer, it's not work and I try to debug it. Because the program itself need hook the input and output, so I can't use gdb to direct debug it, I don't w

GDB: "warning: Can't wait for pid ???: No child processes" (was: GNU accepted as a mentoring organization in GSOC 2014)

Hi! On Tue, 8 Apr 2014 00:20:57 +0800, Zhang Cong wrote: > I am very interesting in that will the gdb server be a workaround for hurd > gdb's > "warning: Can't wait for pid ???: No child processes" problem? > > Can anyone has workable gdb server to do a tes

Re: [RFC] GDB Hurd Fixes

On 01/06/2014 04:56 PM, Thomas Schwinge wrote: > Hi! > > Sorry for the delay, and thanks for the patches you posted. Here are > three patches, based on yours, that I intend to apply if there are no > further comments. I have no further comments (other than saying that IWBN to have the rationale

Re: [RFC] GDB Hurd Fixes

0/2013 01:43 AM, David Michael wrote: > >> (Copying gdb-patches this time.) > > But, we're missing all the context on the gdb-patches@ side. > > Sorry about that--here's an explanation of the problems in GDB's build > process with current Hurd: > >

Re: [RFC] GDB Hurd Fixes

Hi, On Fri, Sep 20, 2013 at 4:47 AM, Pedro Alves wrote: > On 09/20/2013 01:43 AM, David Michael wrote: >> (Copying gdb-patches this time.) > But, we're missing all the context on the gdb-patches@ side. Sorry about that--here's an explanation of the problems in GDB's

Re: [RFC] GDB Hurd Fixes

Hi! On Fri, 20 Sep 2013 09:47:21 +0100, Pedro Alves wrote: > On 09/20/2013 01:43 AM, David Michael wrote: > > [Hurd/GDB issue] > > But, we're missing all the context on the gdb-patches@ side. I'll have a look. Grüße, Thomas pgpw8Re4jp6nN.pgp Description: PGP signature

Re: [RFC] GDB Hurd Fixes

On 09/20/2013 01:43 AM, David Michael wrote: > Hi, > > (Copying gdb-patches this time.) But, we're missing all the context on the gdb-patches@ side. > > Here is an updated patch to successfully build GDB after today's > Hurd/mig changes. -- Pedro Alves

Re: [RFC] GDB Hurd Fixes

Hi, (Copying gdb-patches this time.) Here is an updated patch to successfully build GDB after today's Hurd/mig changes. The awk script changes handle the "auto" keyword being dropped from mig output, and that an "#if TypeCheck" line appears before arg_check_name is defi

[RFC] GDB Fixes

Hi, Recent changes in mig/Hurd have broken GDB's build process. I've appended my changes here and would appreciate any feedback. (Apologies if this is better sent to a GDB mailing list; I'm hoping someone here can tell me if I'm doing something stupid with mig output.) The

Re: GDB/GCC/Hurd GSoC 2013 projects

Hi! I'm running out of time, so in short: On Wed, 26 Jun 2013 18:56:06 +0300, Fotis Koutoulakis wrote: > I would like to express my dearest apologies for the issue that arose > with my lack of communication. > As requested, I also wrote my first report on what I have been up to, > up until this

Re: GDB/GCC/Hurd GSoC 2013 projects

On Wed, 2013-06-26 at 18:56 +0300, Fotis Koutoulakis wrote: > Hello everyone. ... > I also would like to let you know that I am open to any criticism > suggestions. If you have anything to note about my behavior, > performance, methodologies, or just about anything for that matter, > just drop me a

Re: GDB/GCC/Hurd GSoC 2013 projects

outoulakis wrote: > -- Forwarded message -- > From: Fotis Koutoulakis > Date: Wed, Jun 26, 2013 at 12:53 PM > Subject: Re: GDB/GCC/Hurd GSoC 2013 projects > To: Thomas Schwinge > > > Please excuse me for failing to appear at the weekly IRC Meeting. I > promis

Fwd: GDB/GCC/Hurd GSoC 2013 projects

-- Forwarded message -- From: Fotis Koutoulakis Date: Wed, Jun 26, 2013 at 12:53 PM Subject: Re: GDB/GCC/Hurd GSoC 2013 projects To: Thomas Schwinge Please excuse me for failing to appear at the weekly IRC Meeting. I promise that this won't happen again. I would like y

Re: GDB/GCC/Hurd GSoC 2013 projects

Hi Fotis! Neither have you shown up at the scheduled weekly IRC meeting, nor have you given any notice that you wouldn't be able to make it this week. Also, I have not seen any kind of status report from you in a very long time. I know you have been busy with university work before, which is fine

Re: GDB/GCC/Hurd GSoC 2013 projects

Quoting Thomas Schwinge (2013-06-20 12:52:20) > I propose the following scheme: effective now, GSoC students send a > weekly report at the end of each week (so, on Friday, or on the weekend > -- as an exception at the very latest one hour before the following > regular IRC meeting), and regular IRC

  1   2   >