gmane.comp.gdb.devel

Re: [design change] record-replay linux ABI level

Tom Tromey — 2012-05-16T14:56:51

oza> b) I am not much familiar with xml generated C files, and where to
oza> change in gdb, but with that, will the record_linux_system_call be
oza> able to incorporate all conflicting syscall numbers in that case ?

The idea is to extend the current approach.  That is, have a single
generic enum; then map the system-specific numbers to this enum.  The
difference is that the mappings would be generated from the XML files.

oza> define as follows
oza> enum gdb_syscall
oza> {
oza>            /* i386 related syscalls */
oza>            /* ARM related syscalls */
oza>            /* MIPS related syscalls */
oza>            so on..
oza> }

Yeah, I don't like this much.

Tom

Re: [design change] record-replay linux ABI level

oza Pawandeep — 2012-05-16T10:48:05

Tom,

a) yes; The record_linux_system_call is a problem because the
conflicting number would conflict in
{switch} {case} construct of the functions.

b) I am not much familiar with xml generated C files, and where to
change in gdb, but with that, will the record_linux_system_call be
able to incorporate all conflicting syscall numbers in that case ?

c)  there is another way, which is align to current design. (it is not
very very clean but manageable)

define as follows
enum gdb_syscall
{
           /* i386 related syscalls */
           /* ARM related syscalls */
           /* MIPS related syscalls */
           so on..
}

if syscalls share the same number then it is one-to-one mapping.
if at the same number, syscalls are different then add them under ARM
number which would start just after i386.
if there are common syscalls but different number then there would be
shift by a number. then it has to be adjusted in function

static enum gdb_arm_syscall
arm_canonicalize_syscall (int syscall)
{
  enum { arm_sys_

Re: [design change] record-replay linux ABI level

Tom Tromey — 2012-05-15T16:41:53

Oza> I would have liked to think the same; but the way linux-record.h
Oza> addresses all the architecture, the enum sycall, is defiend
Oza> generically.

Oza> what I think is define it in arch files, as syscalls are partially
Oza> dependent on arch, though they follow posix standard.

Oza> so each arch file would have their own map, compare to current generic
Oza> map in linux-record.h

If it really makes things better, it is fine by me.

What do you propose to do with record_linux_system_call?


How about another approach?  Keep the current mapping idea, but extract
the mappings from syscalls/*.xml.  That way we help out two features
with a single data file.

Tom

Re: [discuss] [x86-64 psABI] RFC: Extend x86-64 psABI to support x32

H.J. Lu — 2012-05-15T16:17:35

I will make the change and post a new patch.

Thanks.

Re: [discuss] [x86-64 psABI] RFC: Extend x86-64 psABI to support x32

Michael Matz — 2012-05-15T16:07:30

Hi,

On Mon, 14 May 2012, H.J. Lu wrote:


I'd prefer that.  x32 is a nice short-hand name for the whole thing, but 
not descriptive, unlike LP64.  So, yes, IMO it should be ILP32 in the ABI 
document.


Ciao,
Michael.

Re: Microblaze simulator - Fix missing prototype

Michael Eager — 2012-05-15T13:40:57

I don't see any warning issued in my build, but it is OK
to check this patch in.

Re: [mingw gdb/mi] Separating debuggee output from MI

Noobody — 2012-05-15T12:13:05

 >By running this command, gdb will create a new console for the debugee 
output.
 >i.e. all the redirected IO that you capture in your frontend will 
always be gdb's output.

Hi,

Thanks for the tip!
I am aware of this option, but I would prefer to be able to handle 
input/output
from the debugger itself. The problem is that the Windows console is not
exactly very convenient when it comes to handling standard operations 
such as
copying, pasting, window resizing or similar. Also, keeping all the info and
controls in one window instead of two when debugging would be 
preferrable in my
opinion.

As such, I've been looking for methods to get hold of the debuggees output
directly (which I probably should have mentioned in the first mail).

The method I have now seems to work fine, but I just know too little of 
gdb's
internals to be able to tell whether this could cause problems in the 
future.

Re: Using gdb with a Delphi XE2 project

OBones — 2012-05-15T09:36:36

Thanks, that is crystal clear, I'll have to work around this one way or 
another, back to the drawing board.

Re: Using gdb with a Delphi XE2 project

Jonas Maebe — 2012-05-15T09:21:39

OBones wrote on Tue, 15 May 2012:


Delphi can only generate debug info in the TD32 format, which is not  
supported by gdb.


Jonas

Using gdb with a Delphi XE2 project

OBones — 2012-05-15T08:51:23

Hello all,

Under Windows, I'm trying to debug with gdb an exe file created with 
Delphi XE2
However, I can't find which options I should set for the compiler/linker 
in order for gdb to find the symbols and allow debugging as right now, I 
always get this message:

Reading symbols from C:\Some\Dir\MyProgram.exe...(no debugging symbols 
found)...done.

Does anyone have any suggestion?

Regards

Re: [mingw gdb/mi] Separating debuggee output from MI

asmwarrior — 2012-05-15T07:26:20


Hi, eran, that's was a good solution.

I have such issue several days ago when I used gdb-mi plugin for Codeblocks.

I will ask OBF (the gdb-mi plugin maintainer) to follow your steps.

Thanks.

BTW: I remember once I have such issue, I looked up this in the GDB documents, but no information about this Windows specific issue, So can some one enhanced this in the gdb documents?

Yuanhui Zhang
ollydbg(Codeblocks forum ID)

Re: [mingw gdb/mi] Separating debuggee output from MI

Eran Ifrah — 2012-05-15T06:44:01

Hi,

I also faced this problem while ago when implementing it, what did the
trick for me was to execute 'set new-console on' after starting gdb
but before executing the target
so the sequence should be something like this:



By running this command, gdb will create a new console for the debugee output.
i.e. all the redirected IO that you capture in your frontend will
always be gdb's output.

Note: this command does not work under Linux / Mac. To achieve this on
*NIX, you need to pass
--tty=/dev/pts/XX to gdb for achieving the same effect.

Also, here is a complete reference for codelite's GDB MI implementation:
http://codelite.svn.sourceforge.net/viewvc/codelite/trunk/Debugger/debuggergdb.cpp?revision=5439&view=markup

Look at around line 1025 in function : DoInitializeGdb()


HTH

On Tue, May 15, 2012 at 9:20 AM, Noobody <mail< at >noobody.org> wrote:

[mingw gdb/mi] Separating debuggee output from MI

Noobody — 2012-05-15T06:20:37

I'm currently writing a gdb frontend using the GDB/MI interface, but I have
been experiencing difficulties with differentiating between output by the
debuggee and output from gdb itself.

The documentation mentions target-stream-output, which is prefixed with "< at >",
but it seems it is not actually being used. Instead, target output appears
interleaved with gdb output.

This can cause various problems, so I would like to be able to safely 
separate
target output/input from gdb output/input. Searching for a bit revealed that
this is quite a common problem when writing gdb frontends on windows due to
various limitations of the OS, but I was unable to find a good solution.

I implemented a workaround to this which seems to work, however I am not 
quite
sure whether it is safe to use.

What I'm doing right now is start the debuggee process in suspended mode 
from
the frontend (with CreateProcess and CREATE_SUSPENDED flag), create the gdb
process separately, attach it to the suspended process and then resume it
with

Re: [design change] record-replay linux ABI level

Joel Brobecker — 2012-05-15T05:34:09

If I understand what you are saying correctly, I think that this is
what I had in mind.

NB: I should point out that I have little knowledge of the process-
record code. Just trying to help out with possible solutions if
we think the best option is to have one generic enum.

Re: [design change] record-replay linux ABI level

oza Pawandeep — 2012-05-15T05:20:11

I would have liked to think the same; but the way linux-record.h
addresses all the architecture, the enum sycall, is defiend
generically.

what I think is define it in arch files, as syscalls are partially
dependent on arch, though they follow posix standard.

so each arch file would have their own map, compare to current generic
map in linux-record.h

Regards,
Oza.

On Mon, May 14, 2012 at 8:26 PM, Joel Brobecker <brobecker< at >adacore.com> wrote:

Re: [x86-64 psABI] RFC: Extend x86-64 psABI to support x32

H.J. Lu — 2012-05-14T17:44:04

I used X32 together with LP64.  I can use ILP32 instead of X32 when
LP64 is mentioned at the same time.

Re: [x86-64 psABI] RFC: Extend x86-64 psABI to support x32

H. Peter Anvin — 2012-05-14T17:34:09

As a minor nitpick, I have always used x32 with a lower case x.  The
capital X32 looks odd to me.

-hpa

[x86-64 psABI] RFC: Extend x86-64 psABI to support x32

H.J. Lu — 2012-05-14T17:31:11

Hi,

Support for the x32 psABI:

http://sites.google.com/site/x32abi/

is added in Linux kernel 3.4-rc1.  X32 uses the ILP32 model for x86-64
instruction set with size of long and pointers == 4 bytes.  X32 is
already supported in GCC 4.7.0 and binutils 2.22.  I am now working
to integrate x32 support into GLIBC 2.16 and GDB 7.5   Here is a
patch to extend x86-64 psABI for x32.  Any comments?

Thanks.

Re: [mingw]gdb CVS HEAD build error

Stan Shebs — 2012-05-14T16:15:48

Yeah, I'll take care of this, I habitually forget about mingw not liking 
those directives.

Stan

Re: [mingw]gdb CVS HEAD build error

Eli Zaretskii — 2012-05-14T15:53:57

This is not an incomplete implementation, it's just that we are using
an unportable format specifier.  We should be using what inttypes.h
says (or use LONGEST and plongest).

Re: [design change] record-replay linux ABI level

Joel Brobecker — 2012-05-14T14:56:50

Why not define a table that defines the mapping for every syscall?
We do that for registers -vs- register names, for instance, and that
works very well.

    static enum gdb_syscall arm_syscal_map[] =
    {
      gdb_sys_restart_syscall, gdb_sys_exit, gdb_sys_fork,
      [...]
      gdb_sys_sched_getaffinity, gdb_sys_arm_trap16,
      [...]
    };