Sergey Bugaev, le mar. 11 avril 2023 11:48:45 +0300, a ecrit:
> On Tue, Apr 11, 2023 at 1:50 AM Samuel Thibault
> wrote:
> > Sergey Bugaev, le dim. 02 avril 2023 15:22:33 +0300, a ecrit:
> > > I propose the following: before resetting the exception port, glibc
> > > would fetch the previous one,
On Tue, Apr 11, 2023 at 1:50 AM Samuel Thibault wrote:
> Sergey Bugaev, le dim. 02 avril 2023 15:22:33 +0300, a ecrit:
> > I propose the following: before resetting the exception port, glibc
> > would fetch the previous one, and if it's non-null, it will perform a
> > special synchronous RPC on it
Hello,
Sergey Bugaev, le dim. 02 avril 2023 15:22:33 +0300, a ecrit:
> I propose the following: before resetting the exception port, glibc
> 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 se
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 don't
> recall anythin
"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't completely understand it, but...
gdb in noninvasive mode does not s
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
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 intercepts it once, when it creates the child pro
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. Something else, I think _
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 recently. And
then
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
> CFLAGS=-no-pie etc. to be
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
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_DEBUG a
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
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
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
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
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
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
(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
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)
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
On Fri, Apr 11, 2014 at 8:50 PM, Thomas Schwinge wrote:
>
> Not at all. It "just" needs to be done; the patch has to be brought into
> a form suitable for commit upstream (without a lot of TODO items,
> properly code formatting, and so on), and has to be rebased on top of the
> current upstream ma
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
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 the
> implementation of G
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 use the gdbserver to start the de
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 states(or says, th
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, so I can't use
> gdb to direc
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 want to make the input
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
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
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
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
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
Hi!
On Thu, Jun 20, 2013 at 6:52 PM, Thomas Schwinge wrote:
> More specifically, would Monday, 8 UTC (10 UTC+2, 16 UTC+8) work
> for everyone, typically?
>
That fine for me. And thank you for scheduling your TimeZone for me.
--
Yue Lu (陆岳)
On 06/20/2013 07:52 AM, Thomas Schwinge wrote:
I would expect the GSoC students to typically be available during their
respective daytime, which I think is UTC+2 for Fotis and Justus, and
UTC+8 for 陆岳. (That means, I don't expect you to "switch timezone"
just for GSoC.)
The mentors that are not
Thomas Schwinge, le Thu 20 Jun 2013 12:52:20 +0200, a écrit :
> More specifically, would Monday, 8 UTC (10 UTC+2, 16 UTC+8) work
> for everyone, typically?
That works for me.
Samuel
Hi!
On Mon, 13 May 2013 13:35:37 +0200, Svante Signell
wrote:
> On Sat, 2013-05-11 at 12:03 +0200, Svante Signell wrote:
> > http://lists.debian.org/debian-hurd/2012/09/msg00018.html
> > replied to here gdb has a PATH_MAX issue [...]
> should be sent upstream: where to report, bug-...@gnu.org?
Svante Signell, le Mon 13 May 2013 13:35:37 +0200, a écrit :
> On Sat, 2013-05-11 at 12:03 +0200, Svante Signell wrote:
> > as written in
> > http://lists.debian.org/debian-hurd/2012/09/msg00018.html
> > replied to here gdb has a PATH_MAX issue in addition to the MACH issue.
> > See the second par
On Sat, 2013-05-11 at 12:03 +0200, Svante Signell wrote:
> Samuel,
>
> as written in
> http://lists.debian.org/debian-hurd/2012/09/msg00018.html
> replied to here gdb has a PATH_MAX issue in addition to the MACH issue.
> See the second part of the patch below. This fix was not submitted as a
> De
Samuel,
as written in
http://lists.debian.org/debian-hurd/2012/09/msg00018.html
replied to here gdb has a PATH_MAX issue in addition to the MACH issue.
See the second part of the patch below. This fix was not submitted as a
Debian bug, due to the freeze and lack of feedback. The MACH stuff is
alr
On Fri, 2012-09-28 at 09:56 +0200, Samuel Thibault wrote:
> Thomas Schwinge, le Thu 27 Sep 2012 09:15:23 +0200, a écrit :
> > $ gcc -dM -E -x c - < /dev/null | grep -i mach
> > #define __MACH 1
> > #define __MACH__ 1
> > #define MACH 1
>
> On Linux i386, both "linux" and "i386" mac
Thomas Schwinge, le Thu 27 Sep 2012 09:15:23 +0200, a écrit :
> $ gcc -dM -E -x c - < /dev/null | grep -i mach
> #define __MACH 1
> #define __MACH__ 1
> #define MACH 1
On Linux i386, both "linux" and "i386" macros are defined, which poses
its own problems too.
I'd indeed tend to s
On Thu, 2012-09-27 at 09:15 +0200, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 26 Sep 2012 16:02:29 +0200, Svante Signell
> wrote:
> > gdb does not build from source any longer since gdb-multiarch packages
> > was enabled in 7.4.1-1. The build problems are due to two reasons:
>
> I also once had a
Hi!
On Wed, 26 Sep 2012 16:02:29 +0200, Svante Signell
wrote:
> gdb does not build from source any longer since gdb-multiarch packages
> was enabled in 7.4.1-1. The build problems are due to two reasons:
I also once had a look and came to the same conclusion.
> First the reserved keyword MACH
Thomas Schwinge, le Sun 27 Mar 2011 00:45:11 +0100, a écrit :
> two (different) select routines; nothing else. I had a look at the two
> select routines, and didn't immediatelly spot anything wrong with them.
> But of course, using condition variables, the logic is spread all-over...
You should c
Hi,
On Sun, Mar 27, 2011 at 12:45:11AM +0100, Thomas Schwinge wrote:
> The GDB testsuite uses the expect program to control a GDB process
> (testee). These are connected via a pseudo terminal, by /hurd/term.
> Sooner or later, some action (of expect, of GDB, of ...) confuses the
> term server th
Hi,
On Wed, Oct 29, 2008 at 07:15:46PM +1100, Russell Shaw wrote:
> I've been reading about GNU/Hurd. In linux, a driver for a graphics
> card done in the kernel needs to be tediously debugged using printk()
> and related because it's not running in user context.
>
> Would a graphics driver (that
Russell Shaw, le Wed 29 Oct 2008 19:15:46 +1100, a écrit :
> Would a graphics driver (that needs access to system IO) in Hurd be
> running in a user context where i can use gdb on it?
The Hurd console can be debuggued that way, yes!
Samuel
Hello!
On Sat, Oct 11, 2008 at 06:46:31PM +0100, Pedro Alves wrote:
> > STOPPED_BY_WATCHPOINT () = 0
> > infrun: context switch
> > infrun: Switching context from bogus thread id 1 to Thread 25830.3
>
> ^^
>
> This
On Saturday 11 October 2008 18:26:11, Thomas Schwinge wrote:
> > Doesn't resume the whole shell?
>
> But as I see things we always have ``non_stop == 0'' and thus
> ``resume_ptid = pid_to_ptid (-1)'', so that should be fine, isn't it?
>
Duh! Yes, of course.
> Here is a debugging-enabled run o
Hello!
On Sat, Oct 11, 2008 at 12:47:39AM +0100, Pedro Alves wrote:
> On Saturday 11 October 2008 00:27:06, Thomas Schwinge wrote:
> > On HEAD, when undoing this change (and additionally commenting out the
> > two ``stop_soon = X'' lines in that file), things are fine again.
At the end of this em
On Saturday 11 October 2008 00:27:06, Thomas Schwinge wrote:
> On HEAD, when undoing this change (and additionally commenting out the
> two ``stop_soon = X'' lines in that file), things are fine again.
>
> As most of GDB's internals are a big black box to me, I need help here.
> :-)
>
Eh, I did
Hello!
On Thu, Oct 09, 2008 at 12:55:16PM +0100, Pedro Alves wrote:
> A Thursday 09 October 2008 10:34:24, Thomas Schwinge escreveu:
> > Some of the changes that have been installed between gdb_6_8-branch and
> > HEAD cause GDB to no longer function properly on GNU/Hurd under certain
> > circumsta
A Thursday 09 October 2008 10:34:24, Thomas Schwinge escreveu:
> Hello!
>
> Some of the changes that have been installed between gdb_6_8-branch and
> HEAD cause GDB to no longer function properly on GNU/Hurd under certain
> circumstances.
>
> [EMAIL PROTECTED]:~/tmp/gdb/HEAD.build $ gdb/gdb
Hello!
On Tue, Apr 29, 2008 at 01:28:21PM +0200, I wrote:
> `gnumach-1-branch-gdb-branch'. It may be that
> his effort has never been announced on a mailing list (save from some
> commit-hurd commit messages), so that's done now.
Also I added some bits to this wiki page, to talk about active bra
My gcc-3.x cross-compiler does not produce that same bad code.
(My gcc build is from cvs as of March 15.)
Even if there is something wrong with the code, gcc is definitely behaving
badly. Here is the code from your hurdselect.s that should correspond to
the initialization of INTTYPE.
.LM240:
> What is this "sizeof (MACH_MSG_TYPE_INTEGER_T)"? MACH_MSG_TYPE_INTEGER_T is
> just a macro defining a number:
> #define MACH_MSG_TYPE_INTEGER_T MACH_MSG_TYPE_INTEGER_32
>
> It doesn't seem to make sense to use the sizeof operator on this value.
Oops. That is certainly a bug, but it tur
On Sun, Mar 31, 2002 at 09:45:07PM +0200, Niels Möller wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> What's the definition of mach_msg_type_t? I have the Hurd sources, but
> not Mach sources, around.
typedef struct {
unsigned intmsgt_name : 8,
msg
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
What's the definition of mach_msg_type_t? I have the Hurd sources, but
not Mach sources, around.
> On Sun, Mar 31, 2002 at 01:59:56AM +0100, Marcus Brinkmann wrote:
> > ok, here is some hard data. It turns out that the comparison:
> >*(int *) &ms
On Sun, Mar 31, 2002 at 01:59:56AM +0100, Marcus Brinkmann wrote:
> ok, here is some hard data. It turns out that the comparison:
>*(int *) &msg.error.err_type == *(int *) &inttype
>
> is failing, with the correct number 268509186 on the left hand and a bogus
> number 65536 on the right hand
Hi,
mmh, wait a second:
const mach_msg_type_t inttype =
{ MACH_MSG_TYPE_INTEGER_T, sizeof (MACH_MSG_TYPE_INTEGER_T) * 8,
1, 1, 0, 0 };
What is this "sizeof (MACH_MSG_TYPE_INTEGER_T)"? MACH_MSG_TYPE_INTEGER_T is
just a macro defining a number:
#define M
Hi,
what happens is that the first sanity check fails on the reply message, but
I have no clue why. Maybe gcc generates bad code.
Because the first check has actually four conditions in an if, I will split
it up in multiple ifs, so I see which check exactly is failing.
Breakpoint 1, _hurd_sele
On Sat, Mar 30, 2002 at 08:59:46PM +0100, Marcus Brinkmann wrote:
> Hi,
>
> it seems that poll() is broken. gdb is one of the rare programs using poll
> at all, and I wrote this test program which hangs, too:
Uh, it seems that select() is broken, too:
#include
main ()
{
fd_set fd;
FD_ZE
Hi,
it seems that poll() is broken. gdb is one of the rare programs using poll
at all, and I wrote this test program which hangs, too:
#include
main ()
{
struct pollfd pfd = { 0, POLLIN, 0 };
poll (&pfd, 1, -1);
}
Roland, the last change seems to be:
2001-10-28 Roland McGrath <[EMAIL
On Sat, Mar 30, 2002 at 02:17:01PM -0500, Roland McGrath wrote:
> What's the signal it's taking? That looks like tcsetattr triggering
> SIGTTOU. But that ought to behave properly when you resume it. If gdb is
> doing nothing other than taking SIGTTOU and then retrying the RPC when you
> resume
What's the signal it's taking? That looks like tcsetattr triggering
SIGTTOU. But that ought to behave properly when you resume it. If gdb is
doing nothing other than taking SIGTTOU and then retrying the RPC when you
resume it, then it's fine on that end. The problem is just that term is
giving
* Gordon Matzigkeit writes:
> [EMAIL PROTECTED] (Alfred M. Szmidt) writes:
> Minor nit:
>> char * gdb_realpath (const char *filename) { -#ifdef HAVE_REALPATH
>> +#ifdef HAVE_CANONICALIZE_FILE_NAME + return canonicalize_file_name
>> (filename); +#elif HAVE_REALPATH
> To keep their old semantics,
[EMAIL PROTECTED] (Alfred M. Szmidt) writes:
> Will the following be OK (I didn't bother adding the patch for the
> regenerated configure and config.in, the patches become so messy)?
That looks good.
Minor nit:
> char *
> gdb_realpath (const char *filename)
> {
> -#ifdef HAVE_REALPATH
> +#i
* Mark Kettenis writes:
> It makes sense to me to use canonicalize_file_name. However using
> #ifdef _GNU_SOURCE is not the right way to do this. Use an autoconf
> test for canonicalize filename instead.
Will the following be OK (I didn't bother adding the patch for the regenerated
configure an
Hmm. I am not in a position to actually debug this, but I am reading the
gdb sources and I think I understand what is happening. In gdb/inflow.c is
the following comment and code, which gets run when you do an "attach"
(among other times).
/* If attach_flag is set, we don't know whether
70 matches
Mail list logo
